Re: [Dovecot] Version numbering
On Thu, Mar 29, 2007 at 02:05:13AM +0300, Timo Sirainen (TS) wrote: TS TS I don't think packaging is going to be that big of a problem. If the packagers TS can't handle that, then just don't package it. Development versions don't TS really need binary packages anyway.. And for those using the binary packages, TS the alpha/beta/rc in the version make it pretty easy to understand what kind TS of a release it is. This will work just fine for FreeBSD ports! Greets, Nils -- Simple guidelines to happiness: Work like you don't need the money, love like your heart has never been broken and dance like no one can see you. pgpCL6RlhSssY.pgp Description: PGP signature
Re: [Dovecot] Version numbering
On Thu, Mar 29, 2007 at 10:30:24AM +0200, Nils Vogels wrote: On Thu, Mar 29, 2007 at 02:05:13AM +0300, Timo Sirainen (TS) wrote: TS TS I don't think packaging is going to be that big of a problem. If the packagers TS can't handle that, then just don't package it. Development versions don't TS really need binary packages anyway.. And for those using the binary packages, TS the alpha/beta/rc in the version make it pretty easy to understand what kind TS of a release it is. This will work just fine for FreeBSD ports! Same for pkgsrc. The most important thing though is that the latest format *release* is always supported with security/critical fixes, so people are not forced to track RC's as they are now with 1.0. But there can always be a parallel -devel package for those interested. Geert pgpb3P7rZNfWb.pgp Description: PGP signature
Re: [Dovecot] Version numbering
Quoting Charles Marcus [EMAIL PROTECTED]: By the way - what is 'ultruism'? At first I thought it was a typo, but you did it twice... ;) I'm very consistent with my typos. ;) Substitute the word ALTRUISIM where appropriate. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns!
Re: [Dovecot] Version numbering
On 29/03/2007 22:27, Axel Thimm wrote: On Thu, Mar 29, 2007 at 09:43:48PM +0100, John Robinson wrote: [...] If you use ATrpms packages, you ought to have read the support details (i.e. testing latest software, works for Axel, don't complain to him). No, please do complain to Axel, if something in ATrpms is broken :) Oh well, I thought yellow packages were works for me status, so on that basis one ought not to complain to Axel for anything other than packaging problems. If I've got it wrong, I apologise. Perhaps I'll shut up now :-) Cheers, John.
Re: [Dovecot] Version numbering
Ejay Hire schrieb: I support A. If I get a package from an RPM repository and the version number is 1.3, I will think it is better than 1.2. If I get a package from an RPM repository and the version number is 1.3.unstable, I am smart enough to know that it might be unstable. No offense or doubts about anyone's smartness intended---it's just that it's easier to track upstream bugfixing efforts the way I suggested. /MA
Re: [Dovecot] Version numbering
On March 29, 2007 10:13:37 AM -0500 Eric Rostetter [EMAIL PROTECTED] wrote: Quoting Charles Marcus [EMAIL PROTECTED]: This is *server* software. If someone is not capable or willing to do the research to know what the difference between the packages available are, *regardless* of what numbering scheme Timo settles on, then they have no business running a server and/or deserve what they get if they do so anyway... Yep, and the people who don't look both ways before crossing the street deserve to be run over, so don't bother breaking for them. Just smash them, they deserve it! Yup. Well to stick to software, why shouldn't every single piece of software in the world have its own unique versioning scheme? I mean, it's just a way for the author to make his mark. If someone is not capable or willing to research every single piece of software they run, they have no business running it. Long live Windows! Let's face it, the world is full of stupid and ignorant people, and in the spirit of ultruism we should try to help them. And what is more ultruistic than open source software? You mean normal people, who are simply not versed in our art (and shouldn't have to be, as you say). That doesn't make them stupid and ignorant. If you had to know how TV worked to watch it ... well anyway we'd have better programs I'm sure! I'm sure you were just making a rhetorical point, but I disagree that anything should be done in the spirit of ultruism [sic]. It should be done in the interest of making the best possible software, and part of 'best' means easy to use by some average sysadmin. That has to include the packaging. Wow, this is turning into the thread of threads. I guess it just shows how popular dovecot really is. Since none of us has any say in the matter. What have you wrought Timo?? WHAT HAVE YOU WROUGHT? :-) -frank
Re: [Dovecot] Version numbering
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.MMDD - 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.MMDD, where ~ is ranked lower than even the empty string. -- Magnus Holmgren[EMAIL PROTECTED] (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 pgphBlJzZJiZ8.pgp Description: PGP signature
Re: [Dovecot] Version numbering
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.MMDD, 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'; ?
Re: [Dovecot] Version numbering
Eric Rostetter wrote: 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. I think most new users will look at the web-page and download the latest stable version. As long as both stable and development versions are listed prominently, I doubt many would be confused. Plenty of other packages follow this numbering system, e.g. Linux Kernel, Squirrelmail, and Lilypond. Chris -- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, [EMAIL PROTECTED] IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
Re: [Dovecot] Version numbering
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.MMDD - 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.
Re: [Dovecot] Version numbering
On Wed, March 28, 2007 3:50 am, Joseba Torre wrote:
Hi,
El Miércoles, 28 de Marzo de 2007 04:55, Eric Rostetter escribió:
Why not just put actual (stable) releases in the releases/ directory,
and
put the unstable releases in another directory (unstable, testing, or
some such).
I think this is the easier way. If it's clear that unstable is unstable
(i.e.:
not to be used in production), version numbering is not a problem.
And what about people using OS packaging/port systems? My preference is
for a) (or as another poster suggested, 1.1{a,b,rc}n).
Jim Trigg
Re: [Dovecot] Version numbering
IMHO unstable versions should never go into packages/ports trees. And if they
do, they should be clearly marked as unstable (in debian sid there're some of
these: the package names are foobar-unstable).
Anyway, keeping development releases separated from stable ones is compatible
with the linux kernel style numbering.
Aagur.
El Miércoles, 28 de Marzo de 2007 15:23, Jim Trigg escribió:
On Wed, March 28, 2007 3:50 am, Joseba Torre wrote:
Hi,
El Miércoles, 28 de Marzo de 2007 04:55, Eric Rostetter escribió:
Why not just put actual (stable) releases in the releases/ directory,
and
put the unstable releases in another directory (unstable, testing, or
some such).
I think this is the easier way. If it's clear that unstable is unstable
(i.e.:
not to be used in production), version numbering is not a problem.
And what about people using OS packaging/port systems? My preference is
for a) (or as another poster suggested, 1.1{a,b,rc}n).
Jim Trigg
--
Joseba Torre. CIDIR Bizkaia.
Re: [Dovecot] Version numbering
On Wed, Mar 28, 2007 at 01:39:55PM -0500, Eric Rostetter wrote: I go to atrpms or dag wieers or elsewhere, and it might list both devel and production ones, but it doesn't say that, it just lists version numbers. How am I to know, unless I'm smart enough to go to the original web site and check? I might just assume the highest number one is the one I should run, not knowing it is a devel version. At ATrpms packages in the testing repo are presented in glowing yellow and such in the bleeding in alerting red ;) -- Axel.Thimm at ATrpms.net pgp1Hqu7ynBNG.pgp Description: PGP signature
Re: [Dovecot] Version numbering
On March 28, 2007 3:59:59 PM -0400 John Peacock [EMAIL PROTECTED] wrote: Frank Cusack wrote: You misunderstood that. After the release of 1.2.0, 1.1.x is frozen and development starts again in 1.3.0. And then how do you release 1.2.1? This is a well understood process (even/odd development). Once 1.2.0 is released, all new development moves to 1.3.x. 1.2.1 is a bugfix only (typically implemented first in the 1.3.x branch and then backported). Right, so my point is, you have the same problem and can't tell which 1.3.x is newer than a 1.2.x (on a feature-by-feature or bugfix-by-bugfix basis). I guess it might not matter. But it's nice to say use 1.2.5+ for such-and-such feature and not have to worry that 1.3.0 doesn't actually include that feature. -frank
Re: [Dovecot] Version numbering
On March 28, 2007 4:35:50 PM -0400 John Peacock [EMAIL PROTECTED] wrote:
What this model does is to make many more small releases (no more RC129),
each with a stable feature set.
I don't see how that's different than a/b/rc numbering. You can still
cut as many releases as you like.
1.1.0
1.2.0b1
1.2.0b2
1.2.0rc1
1.1.1
1.2.0rc2
1.2.0rc3
1.2.0
And of course concurrently you can have 2.0{a,b,rc}.
The highest even numbered release is
always the best choice
With a/b/rc the highest numbered release (period, without having to
distinguish between even/odd) without a letter suffix is always
the best choice.
and there is never any feature in an even
numbered release that wasn't developed in the preceding odd-numbered dev
branch.
I also don't see how that's different than a/b/rc numbering. There would
never be a feature in (say) 1.1.1 that wasn't developed in some other
branch.
For reference purposes, see how Apache project handles versions:
http://apr.apache.org/versioning.html
Although this doesn't hew to the even/odd model, it is still about as
air-tight a scheme as is possible with OSS.
That doesn't describe how features from development versions propagate
to release versions. Or even how development versions are numbered.
Otherwise, thanks for the link. I do like that doc.
From the discussion here, the only difference I can see lies in what is
the best version. With even/odd, it's always the highest numbered
even release. With a/b/rc, it's always the highest numbered numeric
release.
-frank
Re: [Dovecot] Version numbering
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/ signature.asc Description: Digital signature
Re: [Dovecot] Version numbering
On March 28, 2007 5:07:30 PM -0400 John Peacock [EMAIL PROTECTED] wrote: But the argument that numeric only works much better for packagers is very powerful, IMNSHO... Yeah, I agree with that.
Re: [Dovecot] Version numbering
On 28/03/2007 19:39, Eric Rostetter wrote: People running Fedora Core run 0.99, and they do not know it isn't production (since it comes with FC, which they don't know isn't production). They ought to; FC in its entirety is devel for RHEL, and this is prominently pointed out all over the F web sites. People running RHEL 5 apparently get a release candidate, but they may think it is production since RHEL 5 is _supposed_ to be production. So they ask here, and get flamed for running a non-production version. It isn't their fault. In a sense, it is; it's certainly not Dovecot's. If distro chooses to include version a.b.c.d.e.f.g.h.i.j.k, consumers of distro ought to take up any problems with distro before they come here. I go to atrpms or dag wieers or elsewhere, and it might list both devel and production ones, but it doesn't say that, it just lists version numbers. How am I to know, unless I'm smart enough to go to the original web site and check? If you're smart enough not to ask Red Hat, atrpms, dag wieers or elsewhere, smart enough not to ask the packager, smart enough to come to the original developer, you really ought to be smart enough to come to the original web site and check. New users (Fedora Core type users) will get confused. What you do on the main site is important, but it is not the whole story from the end-user's point of view. No, it isn't. This list may be for everyone, but versioning etc. is for developers - or at least those who can read the web site or an INSTALL file in the source. Perhaps this all sounds harsh, maybe dovecot would do better for having separate user and devel lists - but right at the moment, dovecot seems to be moving along at a tremendous pace and it's only got one list! Once dovecot's reached 1.0, a sane version numbering system will help put all this to rest. Cheers, John.
Re: [Dovecot] Version numbering
On Wed, 28 Mar 2007 03:46:40 +0300, Timo Sirainen [EMAIL PROTECTED] 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.MMDD - 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
Re: [Dovecot] Version numbering
-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.MMDD - 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-
