Re: Simpler version naming

From: Date: Sat, 19 Feb 2005 12:46:50 +0000
Subject: Re: Simpler version naming
References: 1 2 3 4  Groups: php.pear.qa 
Request: Send a blank email to pear-qa+get-2475@lists.php.net to get a copy of this message
Alan Knowles wrote:
So for 1.4.0 alpha 1, I should release it as 1.4.0RC1 state alpha? That doesn't make sense to me. Hopefully I am misunderstanding what you mean?
There is no such thing as 1.4.0 alpha 1 1.3.0 (stable) 1.3.1 (stable) .. 1.4.0 (alpha) 1.4.1 (alpha) 1.4.2 (beta) 1.4.3 (stable) ... 1.5.0RC1 (beta) 1.5.0RC2 (beta) 1.5.0RC3 (beta) 1.5.0 (stable) <- note this is really messy for version testing now. actually this would be alot better as: 1.5.1RC (beta) 1.5.2RC (beta) 1.5.3RC (beta) 1.5.4 (stable) we dont have a RC 'state', It's just used as a version suffix, personally I think anyone who expects a serious amount of users to test their package while in RC state (above and beyond beta testers) is dreamming, but it's there for those dreamers :) My first reaction to this scheme was "what the crap?!" :) but after 2 minutes of consideration it does have some serious benefits:
1) Most obvious: a simple > test will work, removing the need for version_compare(). Even for RCs, this would be simpler, as you would only need to strip the rc (if (str_replace('RC', '', $version) > str_replace('RC', '' $otherversion) {...}) 2) Documenting how to number your versions is far simpler (and so is validating them) However, I would like to propose one possible addition, which is to say why not make all first major stable releases x.y.0? This would make the scheme above: 1.3.0 (stable) [major release] 1.3.1 (stable) [minor release] .. 1.4.0 (alpha) 1.4.1 (alpha) 1.4.2 (beta) 1.5.0 (stable) [major release] ... 1.5.1RC (beta) 1.5.2RC (beta) 1.5.3RC (beta) 1.6.0 (stable) [major release] This way, users can tell by eyeballing the version number whether there are significant changes. All point releases are either bugfix or alpha/beta releases.
it either introduces magic or forces the user to remember the package state in order to download the file.
It's the magic I want.. - computers are here to serve us lazy people not the otherway round :) Having looked at the proposal, is it trying to clear up the BC rules eg. when to bump xxx to xxx2 to xxx3 etc. and clarify if xxx2-4.0.0 is a valid name? which probably needs a little more explaination (in terms of an RFC explaining the pros/cons on if they should match up..) Yes, my main idea was to combine version naming with BC-breaking releases.
As for magic, I don't see any obvious way to solve this problem, help needed: user requests http://channel.example.com/get/Foo-1.4.3.tgz does it download Foo-1.4.3.tgz or Foo-1.4.3.alpha.tgz? What if the user requests both Foo-1.4.3.tgz and Foo-1.4.3.alpha.tgz? Should we care that both will be downloaded to the HD and imply they are different? Greg

« previous php.pear.qa (#2475) next »