After v1.0 is released, I can finally get back to sane version numbers. But any comments on which one is better: a) Postfix-style: "1.1.UNSTABLE.YYYYMMDD" -> 1.1.0 (stable) b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable) With a) style the releases could be done by simply copying a nightly snapshot to releases/ directory and announcing the changes since the last release. I'm not sure if that's good or bad. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070328/41157bd0/attachment.bin>
On Wed, 2007-03-28 at 03:46 +0300, Timo Sirainen wrote:> After v1.0 is released, I can finally get back to sane version numbers. > But any comments on which one is better: > > a) Postfix-style: "1.1.UNSTABLE.YYYYMMDD" -> 1.1.0 (stable) > > b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable) > > With a) style the releases could be done by simply copying a nightly > snapshot to releases/ directory and announcing the changes since the > last release. I'm not sure if that's good or bad.For the sake of packagers, stick with numbers, always incrementing. Makes our lives a ton easier. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070327/76ff3258/attachment.bin>
Aredridel wrote:>> b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable) >> >> With a) style the releases could be done by simply copying a nightly >> snapshot to releases/ directory and announcing the changes since the >> last release. I'm not sure if that's good or bad. > > For the sake of packagers, stick with numbers, always incrementing. > Makes our lives a ton easier.As the resident Perl version[1] expert, I concur that numbers and only numbers are the way to go... John 1) http://search.cpan.org/~jpeacock/version-0.71/lib/version.pod -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Blvd Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
On 02:46:40 2007-03-28 Timo Sirainen <tss at iki.fi> wrote:> After v1.0 is released, I can finally get back to sane version numbers. > But any comments on which one is better: > > a) Postfix-style: "1.1.UNSTABLE.YYYYMMDD" -> 1.1.0 (stable) > > b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable) > > With a) style the releases could be done by simply copying a nightly > snapshot to releases/ directory and announcing the changes since the > last release. I'm not sure if that's good or bad.I'd say b) Simply because it's nicer imho... :)
Quoting Timo Sirainen <tss at iki.fi>:> a) Postfix-style: "1.1.UNSTABLE.YYYYMMDD" -> 1.1.0 (stable)Not my favorite, but works for me. Seems good for Timo, since he likes to release dated snapshots anyway.> b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable)I don't like this, as the average new user has no idea that the odds are unstable, and runs them, then gets flamed for it, etc. No matter how well you document it on the web/wiki, people are going to mistakenly run the odd number releases and get in trouble.> With a) style the releases could be done by simply copying a nightly > snapshot to releases/ directory and announcing the changes since the > last release. I'm not sure if that's good or bad.Why not just put actual (stable) releases in the "releases/" directory, and put the "unstable" releases in another directory (unstable, testing, or some such). -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns!
On Wed, Mar 28, 2007 at 03:46:40AM +0300, Timo Sirainen wrote:> After v1.0 is released, I can finally get back to sane version numbers. > But any comments on which one is better: > > a) Postfix-style: "1.1.UNSTABLE.YYYYMMDD" -> 1.1.0 (stable) > > b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable) > > With a) style the releases could be done by simply copying a nightly > snapshot to releases/ directory and announcing the changes since the > last release. I'm not sure if that's good or bad.I'm not claiming to be real familiar with the various numbering methods, but I'd opt for a simple approach that doesn't require "inside" knowledge. As such, I do NOT like option b. I'd prefer that stable releases be kept separate from unstable ones, and that the stable ones be numbered: X.Y.Z where: X is the major version (changes only for major feature updates), Y is the minor version (changes for minor feature updates), and Z is more or less a patch level. -- Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: sfs at umn.edu Office of Information Technology Voice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
28.03.07 ? 03:46 Timo Sirainen ? ????? ?????? ?????(?):> After v1.0 is released, I can finally get back to sane version numbers. > But any comments on which one is better: > > a) Postfix-style: "1.1.UNSTABLE.YYYYMMDD" -> 1.1.0 (stable) > > b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable) > > With a) style the releases could be done by simply copying a nightly > snapshot to releases/ directory and announcing the changes since the > last release. I'm not sure if that's good or bad.a) variant would be nice =) -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Wed, 28 Mar 2007 03:46:40 +0300, Timo Sirainen <tss at iki.fi> wrote:> After v1.0 is released, I can finally get back to sane version numbers. > But any comments on which one is better: > > a) Postfix-style: "1.1.UNSTABLE.YYYYMMDD" -> 1.1.0 (stable) > > b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable)Whilst I understand objections to type a) version numbering I think the confusion that would be generated by type b) version numbering outweighs the issue of alpha version numeric (or a combination thereof) versioning. My vote is for type a) versioning. Regards James Turnbull
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/28/07 9:46 am, Timo Sirainen wrote:> After v1.0 is released, I can finally get back to sane version numbers. > But any comments on which one is better: > > a) Postfix-style: "1.1.UNSTABLE.YYYYMMDD" -> 1.1.0 (stable) > > b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable) > > With a) style the releases could be done by simply copying a nightly > snapshot to releases/ directory and announcing the changes since the > last release. I'm not sure if that's good or bad.I vote for a) as it make it very clear which is the stable version and which is not. theoretically the unstable versions shouldn't be in production, so production style versioning for the unstable versions shouldn't really be necessary. my 2yen worth. Alan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGCfbDE2gsBSKjZHQRAv26AJ9Eg0txNcfUYBz2kEIEz5wuhYiBdQCdEO4B N1jw5RuhOKpr/AA+SDun4aY=3TL5 -----END PGP SIGNATURE-----
Timo Sirainen wrote:> After v1.0 is released, I can finally get back to sane version numbers. > But any comments on which one is better: > > a) Postfix-style: "1.1.UNSTABLE.YYYYMMDD" -> 1.1.0 (stable) > > b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable) > > With a) style the releases could be done by simply copying a nightly > snapshot to releases/ directory and announcing the changes since the > last release. I'm not sure if that's good or bad.My only issue with version a) is that it's not always clear if N.M.UNSTABLE came before or after N.M.0 ... or is the unstable development after that. This ambiguity, I guess, comes from projects who step from 1.0.5 to 1.0.90 as the 1.1 pre-release. Otherwise, a) is the go. -- Curtis Maloney cmaloney at cardgate.net
On Wed, Mar 28, 2007 at 03:46:40AM +0300, Timo Sirainen may have written:> > b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable)I'd really prefer using type b versioning as then there is no ambiguity when attempting to build packages for dovecot. There are many examples in the Debian repository where exceptions to the versioning numbers had to be made in order to accomodate non-numeric versioning. I think this can be made very clear on the website. If someone messes it up anyway, perhaps they should learn to read documentation before installing. -- http://www.delink.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20070328/af3dce0b/attachment.bin>
On Wed, 28 Mar 2007 03:46:40 +0300 Timo Sirainen <tss at iki.fi> wrote:> After v1.0 is released, I can finally get back to sane version > numbers. But any comments on which one is better: > > a) Postfix-style: "1.1.UNSTABLE.YYYYMMDD" -> 1.1.0 (stable) > > b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable) > > With a) style the releases could be done by simply copying a nightly > snapshot to releases/ directory and announcing the changes since the > last release. I'm not sure if that's good or bad.I vote fore style 'a'. -- Gerard A bachelor never quite gets over the idea that he is a thing of beauty and a boy for ever. Helen Rowland -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20070328/3ca67df3/attachment.bin>
On Wednesday 28 March 2007 02:46, Timo Sirainen wrote:> After v1.0 is released, I can finally get back to sane version numbers. > But any comments on which one is better: > > a) Postfix-style: "1.1.UNSTABLE.YYYYMMDD" -> 1.1.0 (stable) > > b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable) > > With a) style the releases could be done by simply copying a nightly > snapshot to releases/ directory and announcing the changes since the > last release. I'm not sure if that's good or bad.Also as a packager, I must remark on the ambiguity of (a). Normally letters come after numbers in order. Luckily in Debian, it can be transformed into "1.1~UNSTABLE.YYYYMMDD", where "~" is ranked lower than even the empty string. -- Magnus Holmgren holmgren at lysator.liu.se (No Cc of list mail needed, thanks) "Exim is better at being younger, whereas sendmail is better for Scrabble (50 point bonus for clearing your rack)" -- Dave Evans -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20070328/3c39df7d/attachment.bin>
On Wednesday 28 March 2007 10:48, Magnus Holmgren wrote:> Also as a packager, I must remark on the ambiguity of (a). Normally letters > come after numbers in order. Luckily in Debian, it can be transformed > into "1.1~UNSTABLE.YYYYMMDD", where "~" is ranked lower than even the empty > string.I agree .. I vote for the linux kernel (old) style .. 'b' -- <?php echo ' Emiliano Gabrielli (aka AlberT) ',"\n", ' GrUSP founder - ZCE ',"\n", ' AlberT_at_SuperAlberT_it - www.SuperAlberT.it ',"\n", ' IRC: #php,#AES azzurra.com ',"\n",'ICQ: 158591185'; ?>
On 28/03/2007 01:46, Timo Sirainen wrote:> After v1.0 is released, I can finally get back to sane version numbers. > But any comments on which one is better: > > a) Postfix-style: "1.1.UNSTABLE.YYYYMMDD" -> 1.1.0 (stable) > > b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable) > > With a) style the releases could be done by simply copying a nightly > snapshot to releases/ directory and announcing the changes since the > last release. I'm not sure if that's good or bad.b) because it's more straightforward for package management systems, and most people use pre-packaged distributions. Anyone who's building from source themselves ought to understand either method and/or read the INSTALL file which tells them about versioning. (Well, it doesn't now, but it would, right?) Cheers, John.
On Wed, Mar 28, 2007 at 03:46:40AM +0300, Timo Sirainen wrote:> After v1.0 is released, I can finally get back to sane version numbers. > But any comments on which one is better: > > a) Postfix-style: "1.1.UNSTABLE.YYYYMMDD" -> 1.1.0 (stable) > > b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable)b) :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20070328/c7b79829/attachment.bin>
Timo Sirainen wrote:> After v1.0 is released, I can finally get back to sane version numbers. > But any comments on which one is better: > > a) Postfix-style: "1.1.UNSTABLE.YYYYMMDD" -> 1.1.0 (stable) > > b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable) > > With a) style the releases could be done by simply copying a nightly > snapshot to releases/ directory and announcing the changes since the > last release. I'm not sure if that's good or bad. >A lot of the posts in this thread seem to be debating between version numbering and storage layout, which are not mutually exclusive considerations. I would go with the even-odd numbering scheme, along with stable/devel storage layout. On the download page, keep the stable series at the top, with devel/experimental listed below. Perhaps you first get a page describing the stable and devel series, and must make a selection before even showing download links. Plus, put the stable series in /stable or /releases, and the devel series in devel/ or /experimental or whatnot. If people still manage to get confused about which version to run after all that, well, should you be responsible for configuring the software for them too? You have to stop lowering the common denominator at some point.
Timo Sirainen schrieb:> After v1.0 is released, I can finally get back to sane version numbers. > But any comments on which one is better: > > a) Postfix-style: "1.1.UNSTABLE.YYYYMMDD" -> 1.1.0 (stable) > > b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable) > > With a) style the releases could be done by simply copying a nightly > snapshot to releases/ directory and announcing the changes since the > last release. I'm not sure if that's good or bad.I suggest a), consider however adding a public list that shows the release dates. The latter is helpful if you start fixing bugs in the stable release and the unstable at the same time, so that people can easily check the bug fix date for the common fixes.
--On Wednesday, March 28, 2007 3:46 AM +0300 Timo Sirainen <tss at iki.fi> wrote:> After v1.0 is released, I can finally get back to sane version numbers.Have the RC's released new features as well as fixed bugs? I've been hesitant to upgrade to an RC because they seem to be released so frequently and I have no idea if one is more or less stable than another. This uncertainty is a big show-stopper to upgrading. It would help if, for a given RC, we knew exactly what known issues that RC had. (Is that in the wiki?) I'd suggest that a "version" be assigned only to something that should get spread around. A nightly snapshot should get the version it was based from and a timestamp suffix of when it was extracted from CVS. (Were this Subversion, I'd append the repository revision, instead.) The snapshot is not a "version" but a convenient download from CVS. It should be exactly what you get with the same timestamp used in a checkout command. Apache's versioning scheme (posted by John Peacock) looks good to me: <http://apr.apache.org/versioning.html>