Release Numbering Decision Vote
The community need to make a decision about the versioning scheme for our releases. This is a decision we cannot easily change later. We must get it right now.
The way we vote is important.
We cannot just vote for multiple formats of which one is to continue from 4.2.4. The reason is that this will most likely end in a minority decision. The people that vote for 4.2.4 may not do it because of the format but for other reasons.
So to ensure the democratic process leads to a decision that a majority supports we need to take it in two steps. And to ensure that we do not mix things up we do one first and when we have the decision we take the 2nd step (if required).
The process will be
- and then vote (non anonymous)
The arguments will not be in threaded discussion. You simple add your arguments to the pros and cons. To argue you add your con. Use short sentences in bullet format like already started.
This topic is a short lived topic. When decision is made the result is put on the ReleasePlan
and this topic is deleted.
Decision 1 - Do we continue the release number series from TWiki (or do we make a new)?
- Yes. Continue with 4.2.4, 4.3, 5.0 etc
- No. New version
- The result was a very clear No. 21 voted No. 1 voted Yes.
- Details can be seen in rev 29 of this topic.
Decision 2 - What versioning scheme should we use?
There are at 2 proposals (one with the choice between 2 or 4 digit year)
- 1.0.0, 1.0.1, 1.1.0, 2.0.0 etc
- 09.01.01 (yy.mm.patch1) or 2009.01.01 (yyyy.mm.patch1)
- The Result was that we use the 1.0.0 scheme. 15 voted for 1.0.0, and 5 voted for y.m.p. One had voted 1.yy.mm which I interpreted as y.m.p since it did not change the result discussing if it was invalid.
note that we do not decided on 2 or 4 digits on the date option. That can easily be decided later. Splitting it in 3 will disturb the voting.
question: couldn't be patch easily replaced by day or are several patches per day reasonable?
- yup, - SD (i didn't worry too much about it, as it won't happen often, its just useful to have as a possibility)
Arguments for 1.0.0
- This is a classical numbering scheme which most software uses. Kernel, Open Office, Firefox, Perl, etc etc
- The format tells a clear message on the level of change. When the first digit changes you know it is a real major change with huge feature additions. When the 2nd digit changes it is more minor changes with some enhancements. And when the last digit changes the change is just bugfixes and you know you can upgrade in minutes without worries.
- This, from one admin's point of view, is the expected and easiest format to understand.
- The format has no time trap in it. If you announce that next release is 1.2.4 there is no problem when the release cannot keep its forecasted release date. A project that releases "when it is ready" (which is our policy) is better off not having to change the predicted version number all the time.
- Without the time trap we can create a branch on SVN with the major.minor in the name (Release0101) and not having a problem with a delay of a month or two. Patches can be built from same release branch.
- Even though the 1.0.0 format does not tell the user how old the release is, writing the version as "1.0.0 (05 Dec 2008)" fully resolves this little issue. There is no reason the date has to be part of the version number to tell that story. Anyways, to find when was perl 5.6.3 released, just google "perl releases" and you find as first hit http://search.cpan.org/dist/perl/pod/perlhist.pod this page... it takes 10 seconds...
- Patch releases do not signal a false old date. When you on the 12 Feb 2010 see that you can upgrade to "1.1.4 (02 Feb 2010)" you know it is a fresh nice new release from Feb 2010. If you see 2009.06.04 which is a patch release 4 from the 2009.06 minor release, you signal "old 2009". Naturally you could call it "2009.06.04 (12 Feb 2010)" but that would be a complete message confusion.
- Existing infrastructure is based on this scheme
- The 1.0.0 scheme tells the difference between major and minor
- The 1.0.0 scheme still tells WHEN the release is from as long as the version number is followed by the date. E.g "1.1.4 (02 Feb 2010)"
- The current infrastructure does support a year.month scheme UNLESS you are sure that you release the month that you planned. This will most likely never happen unless we change to fixed release schedule. The core developers seem to agree that we release when it is ready. So we will always have trouble with a year.month scheme in the infrastructure if we want the name to match the actual month we release.
- A 1.0.0 scheme enables us to make a release roadmap with named releases. 1.0.0, 1.1.0, 1.2.0, 2.0.0 etc. It is practically impossible to do that with a year.month release scheme. We cannot possibly know what month we release in 6 months to 2 years from now.
- The need for predictable names means that we move back to Peter Thoeny's named release model where releases have a name and a date. We faught hard to get away from that and on to the release scheme we have today.
Arguments for 09.01.01 or 2009.01.01
- its becoming more common as Engineers and marketers realise that users want information, not marketing in versioning. - Sun has been doing it with Solaris for a few years.
- Sorry but Sun has never use this for Solaris. In fact, it uses a mix of the 2. The major version number is incremented on each release, and they release ISO patch level several times afterwards. These ones are named with the date M/YY: Solaris 10 10/08, Solaris 10 5/08, Solaris 9 9/05, etc... OpenSolaris, on the other hand, uses this YYYY.MM scheme
- The release version tells when the last major or minor release is from.
- Simply numbers the release when it is released. No time trap need be implied.
- No time trap for svn branches either - make a Release or Maintainance branch, and tag when ready.
- No risk of overlap with TWiki.net version numbers.
- It's unorthodox but honest; would make us somehow exceptional
- makes it easy for a user/admin to know both what version they run, and how long ago it was released (anyone remember offhand when Perl 5.6.3 was released?
- no change to infrastructure, as its actually still 3 numbers.
Adding your vote
You can change your mind as new arguments may change your mind.
The vote ends on 09 Nov 2008 - 19:00 GMT. Then Kenneth counts the vote.
To repeat, we have 2 viewpoints:
Please add your vote to the table below: