Re: Simpler version naming
| From: | Greg Beaver | 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:
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.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:
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? Gregit 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.