Re: RFC Version Naming

Some things that sound a bit strange to me: "To replace the existing standard with one a far simpler one, " -> imho there is one one too much :-) "moving from Major Package Versions" -> did you mean "between Major package versions" or "raising the major version"? in "Bug fix only Releases" and "Feature addition Releases": there might be "internal" releases of 0.2 -> 0.3 and then a 0.3.1 fix might come up. Is this allowed to your document? So we would have 0.2 -> 0.3.1 on the server. Shouldn't we demand a x.y.z numbering for all releases? E.g. 0.2.0 instead of 0.2. Or is both allowed? Or should the z be left out if zero (is this a recommendation or requirement)? "Appending RC releases": I'm unsure if the RC-naming is really required. Why wouldn't I just issue a 0.99 before 1.0 instead of having 1.0.0RC1 with 1.0.0 following? And please note that imho the document should clearly state that release-candidates should be marked as beta instead of stable. Imho the package-state-suffixes should be left out - as you did in your document. This way we avoid e.g. a alpha release of "0.3beta" or things like that. Imho we shouldn't use redundant information, but ensure that the state is displayed in all places where the version- numer is should (in installer and pearweb). Stefan On 3 Apr 2004 at 10:35, Alan Knowles wrote: > Attached is the RFC on the revised version naming standard, Open for > comments.. > > also available at > > http://devel.akbkhome.com/svn/index.php/akpear/RFC/VersionNumbering.txt