I more or less agree with Henrik's points. That said… my primary concern is with the source name rather than the version. My opinion is… the source should be called 'drizzle' … because every subsequent release is still 'drizzle' and is intended to replace older versions of 'drizzle'. The versioning should determine branch/compatibility/etc … but not the source name itself. Every release is 'drizzle... If packagers want to package multiple versions then they can opt to package it as 'drizzle7.1' or 'drizzle71' or 'drizzle8' or whatever… however by making the source name different with every release *upstream* then that is where we start to have issues downstream as mentioned previous regarding Fedora.
As for versioning… I like the idea that 7.1 is a major release… anything after such as 7.1.x, 7.1.y, 7.1.z I would hope would be compatible with 7.1. I would expect potential compatibility issues when upgrading to 7.2, or 8.x. As it stands now… 2012.XX.YY just doesn't mean anything to me other than "this is a new release". --- derks On Jan 16, 2012, at 3:58 PM, Clint Byrum wrote: > Excerpts from Henrik Ingo's message of Sun Jan 15 23:28:38 -0800 2012: >> On Mon, Jan 16, 2012 at 2:54 AM, Stewart Smith <[email protected]> >> wrote: >>> On Fri, 13 Jan 2012 22:44:48 +0200, Henrik Ingo <[email protected]> >>> wrote: >>>> Ok, good. This was why I raised the issue in the first place. >>>> >>>> So back to the drawing board: Could we just behave like normal people >>>> and release drizzle-version.tar.gz? Stewart? >>> >>> Most packaging systems don't really understand things with a -beta or >>> -rc suffix to be before a package without it. >>> >> >> I don't see the problem. Surely 2012.01.30-beta < 2012.01.31-rc < >> 2012.01.32-stable and what the tag is (or even if there is none) is >> completely irrelevant. >> > > 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. > > 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. > >>> 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. > >> 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. > >> 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. --- derks _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
