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... henrik -- [email protected] +358-40-8211286 skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559 _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
