Excerpts from Henrik Ingo's message of Tue Jan 17 07:57:28 -0800 2012: > On Mon, Jan 16, 2012 at 11:58 PM, Clint Byrum <[email protected]> wrote: > > Forgive me for jumping into this part of the discussion a bit unarmed > > with facts, but I am puzzled as to how we got here. > > Oh, you as representing 2 distributions are perhaps the main consumer > of the source releases, please do comment! > > > Its not clear to me why the current tarball is versioned 2012.01.30. Why > > aren't we just versioning each tarball on the way to 2012.01.30 as the > > day it is released? If a second beta/rc/etc. is needed on said day, then > > that would be 2012.01.16.1, and if we go past 9 of those (given hours of > > build time and testing, this seems unlikely) then move on to letters. Or > > the revno can be used for subsequent patches on the same day. It is rather > > confusing to have a future-dated tarball that is unqualified in its name. > > See, this is the reason the current system is bad, even you are > confused. The meaning of the numbers in our most recent release is: > > 2012 = year of the release > 01 = month of the release > 30 = how many releases were done of the Fremont series, (ie *not* day) > > To compare, the previous release, made in November, was 2011.11.29. So > the last digit was one less than 30. > > Otoh the release names on launchpad, which each download file is part > of, are dates. So they are not identical to the release numbers in the > source tar.gz. It's a mess... Even the people doing the releases are > confused... > > >> > Also, using bzr revnos and dates gets us daily/snapshot builds that can > >> > be packaged very easily and we don't have to have a human remember to > >> > bump a point release. > >> > >> We should continue to use the current system with bzr revnos for > >> snapshots, there is no need to change that. > >> > >> For the first part of the version number... even if it looks like a > >> date, it's just a tag. It could be anything. Pandora uses the latest > >> tag from bzr. In other words, we can still choose to call our versions > >> 7.1.30.x or 2012.01.30.x, just not both. (x is the revno that is > >> automatic.) > >> > >> For major releases, unfortunately a human just has to bump the number. > >> I see that this is a very hard demand as nobody has thought of doing > >> that for the past 9 months that you have been releasing Fremont > >> releases, but just continuing to release Drizzle7 again and again > >> every year is just very wrong and needs to be fixed asap. > >> > > > > I'm not so sure I would agree with this. If there have been no backward > > incompatible changes, then it seems fine to me to just keep calling it > > "drizzle7" unqualified. Yes, its got more features, and bug fixes, but > > I would presume that an app written to work with elliot will still work > > with fremont. If thats not necessarily true, then 7.1 does seem to be > > the prudent thing. > > Oh no, many people would not agree with that: > > - A new release, ie 7.1 instead of 7 is a hint to people there is new > stuff to try out. Remember that even if we don't do it, theoretically > we should also release bug fix releases of elliot. (I will not even > attempt to speculate what version number such a release would have :-) > > - Some distributions specifically don't want to upgrade to versions > that have any new features, they only do bug fix upgrades through the > lifetime of the distribution. It took us a long time to educate them > that that is exactly how MySQL releases do too so they should just > consume the new releases that are updates to a major release. (Where > major is 5.0.x 5.1.x and 5.5.x.) > > - DBAs are a conservative lot and definitively don't want new > features within a release series (I got asked about this release > policy a lot when selling MySQL - they always wanted to hear we don't > add features past a GA date). Hence someone should be able to stay on > drizzle 7 and not get any new features. New features should be called > something else, like drizzle 7.1. > > >> So, should we go with 7.1.x or 2012.01.x? As much as you like the date > >> based releases, I'm for the 7.x.x numbering. Currently we make > >> releases like 2011.03.14, 2011.11.13 and 2012.01.30. You think it's > >> convenient to just slap a date on it and not care. But for users this > >> is actually confusing: from those numbers you'd thing that 2011.x are > >> part of the same series and 2012.01 is an upgrade. But this is wrong, > >> in fact 2011.11.13 is elliot and 2011.11.13 and 2012.01.30 are > >> fremont. Hence the current versioning scheme - while deterministic - > >> is nonsensical. > >> > > > > IMO, the 7.x is quite arbitrary, and I like the date based releases as > > well.. but only for development milestones and for series releases (GA). > > > > I've stated in the past that elliot releases should never have been > > allowed to be date based. 2011.03.14 has meaning as a point in time > > where backward compatibility is guaranteed, so patches to this should > > be 2011.03.14.01, rising from there. If not an arbitrary monotonically > > increasing number, then use the revno from the elliott series branch. I > > have to agree that its incredibly confusing to version the patch releases > > the same way as milestones in the development effort. Doing so means > > definitely needing to add the 7.1 if we release another GA and intend > > to carry on the practice. > > Note that there was no 2011.03.14 release. The tar ball release is > 2011.03.13. It was released on 2011-03-15 (a date). Why the launchpad > release name is 2011-03-14 is a good question... > > Confusing? Yeah... > > So an upgrade to elliot might be versioned 2011.03.15, one higher than > 2011.03.14. Or if it was to be something else, then we would be > completely lost. But we are already... > > >> If we want to do date based numbers, it should be like Ubuntu, where > >> the version number comes from the release month of the release. Ie > >> current beta and rc releases are already labeled 12.04-beta, not 12.01 > >> (there is no such ubuntu release). To do this, we would need to know > >> in advance which month a development series will be released as > >> stable. Since that will never happen with this gang (and is > >> unrealistic with 12 month cycles, imho), we should just use 7.1.x > >> version numbers. > >> > > > > Right, if milestones are going to be numbered the same across series then > > a traditional semantic version numbering scheme is preferable. > > > > However, you don't need to know the end release date to use date based > > release numbers. You just have to know when you marked the GA, and then > > only patch that. This goes for Ubuntu too. We release patched LTS CD's > > as 10.04.1, 10.04.2, etc. We have let an LTS slip before as well. Dapper > > was not 6.04, but 6.06, so the version number is never certain, and > > nothing breaks if its pushed out a bit. > > > > That's true. Even so, it seems the current system is confusing and > nobody knows what the version number is. An arbitrary number that > doesn't look like a date, like 7.1.x could be used across the whole > series, both before and after GA, and there wouldn't be any > assumptions for which day the GA release should happen or did happen. > > Otoh, if people want the release numbers that look like dates but are > not, then at least the 7-based numbering needs to die. It is either > or. But imho, and this email should be a perfect illustration why, the > current looks-like-a-date-but-is-not versioning is the one who > deserves to die...
Thanks for setting me straight Henrik. I think I understand it all now. I think the current scheme is ok, but really, I would almost suggest starting counting at 100 or 40 just to make it clear that it is *not* the day of the month. The 7.1 is fine to denote that this is a "new thing" over "7". I'd also be in support of a move to purely semantic version numbers, so 7.1.0, then 7.1.1, etc. etc. _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
