Re: RFC Version Naming

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 Regards Alan ------------------------------------------------------------------------ RFC Version Naming ------------------------ Version 1 As discussed previously on pear-group, where a full consensus could not be reached on the version naming standard, below is the proposed replacement RFC, which attempts to address the issues. The issue ----------- Pear-group announced a versioning naming standard which unfortunatly failed to explain the reasons behind the decisions made. The aim of the previous standard was * formalize the version naming of packages. * fix problems with version_compare going from 1.0RC1 to 1.0.1 * to introduce a rule stating 'no-stable releases before 1.0' * Solve release naming for My_Package2 (second releases) It also attemtped to introduce a number of more controversial ideas * Make the package status more visible.

I still havent seen any reason why this is not a good idea. It might not be a good idea to have it redundant in the package.xml, but its certainly a good idea to have the state in the version name. I mean we get people on the irc channel saying that version 1.y.z has issues. From that I know nothing about the state of the package. This is however a criticial information. Not only reminds this the person asking the question that he may be using alpha software, but it also makes it clear to me that this person is using alpha software. This makes a big difference to me.

* Force developers to release an RC release for all packages.

This is just FUD. It forced developers to release 1 RC in the entire lifetime of a package. Anyways the purpose of this was to give the PEAR community a chance to actually prevent stupid mistakes before going stable. But this has been "moved" to the QA RFC which states that all stable releases need to be approved by the QA team.

The Solution --------------- To replace the existing standard with one a far simpler one, that formalizes pretty much the previous status quo.

As I have said before I like this format alot better. However I dont agree in one point and this one is very important to me. This is also where this standard is not simpler. This is in allowing versions in the x.y standard. The previous regulation clearly stated that it always needs to be x.y.z. This is because x.y can lead to stupid mistakes (1.0 < 1.0.0). This my only happen once in all of PEAR, however I really dont understand where the effort is to add another ".0" to prevent this mistake. Also I think that if we are going to superseed anything we need to think more along the lines of what are we going to change from how things were before and do we have a very good reason (good is not good enough in this case imho).

- Added not that this document does not officially define BC issues.

s/not/note/ Anyways you know all of my arguments and you have chosen not to include them in this RFC. I just wanted to state them once more in public so that the rest of the world also knows :-) In the current form I will vote -1 as it simply fails to provide "very good" reasons to change things which are imho not even close to bad ideas (appearently they are controversial however). regards, Lukas Smith smith@backendmedia.com _______________________________ BackendMedia www.backendmedia.com berlin@backendmedia.com Linn Zwoch Smith GbR Pariser Str. 44 D-10707 Berlin Tel +49 30 83 22 50 00 Fax +49 30 83 22 50 07