surorisingly interesting discussion over a topic that seems so simple ;-) how about following http://semver.org? that seems to be simple and making sense?
Sent from my galaxy tab On Jan 17, 2012 6:54 PM, "Clint Byrum" <[email protected]> wrote: > 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 >
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
