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

...

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.

+1

I don't like either a) or b), and would prefer the above - stable releases are marked as that, and unstable releases are in a separate directory - so someone has to intentionally go and get them if they want them.

Actually, I would even prefer something like:

stable unstable nightly

where the unstable are actually specific nightlies that Timo considers ready for testing (kind of like all of these rc's), and the nightlies are just that - for those that like living on the edge - use at own risk, no guarantees, blah blah.

My .02 clad coins worth...

--

Best regards,

Charles

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.

Aaaaaagur.

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.

Quoting Chris Wakelin c.d.wakelin@reading.ac.uk:

...

...

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.

If the two are not kept in the same directory, and if they are downloading from the official site instead of some RPM repository or such, then yes.

But, the fact is, many will not get the package from the web site but from some ftp site, web listing of the directory, or an RPM repo (apt/yum/etc) or some such, and not know what the version numbers mean.

I don't really care myself, I'm just trying to look out for others.

Chris

-- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wakelin@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094

-- Eric Rostetter The Department of Physics The University of Texas at Austin

Go Longhorns!

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)

I like (a) but even better I like 1.1.0{a,b,rc}N -> 1.1.0

Even-odd is confusing because you can't tell which 1.1.x versions are newer than any 1.2.y version.

-frank

On March 28, 2007 8:46:08 AM +0200 Juergen Daubert jue@jue.li wrote:

On Tue, Mar 27, 2007 at 11:28:24PM -0700, Frank Cusack wrote:

...

...

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)

I like (a) but even better I like 1.1.0{a,b,rc}N -> 1.1.0

Even-odd is confusing because you can't tell which 1.1.x versions are newer than any 1.2.y version.

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?

-frank

On March 28, 2007 3:59:59 PM -0400 John Peacock jpeacock@rowman.com 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

On March 28, 2007 4:35:50 PM -0400 John Peacock jpeacock@rowman.com 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

On March 28, 2007 5:07:30 PM -0400 John Peacock jpeacock@rowman.com wrote:

But the argument that numeric only works much better for packagers is very powerful, IMNSHO...

Yeah, I agree with that.

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.

On Thu, 29 Mar 2007 10:30:24 +0200 Nils Vogels nivo+sender+9bb457@is-root.com wrote:

TS> TS> I don't think packaging is going to be that big of a problem. If TS> the packagers can't handle that, then just don't package it. TS> Development versions don't really need binary packages anyway.. TS> And for those using the binary packages, the alpha/beta/rc in the TS> version make it pretty easy to understand what kind of a release TS> it is.

This will work just fine for FreeBSD ports!

As an example, the FreeBSD ports list:

Port: postfix-current-2.4.0.r9,4 # the latest version Port: postfix-2.3.8,1 # Newest stable version Port: postfix ??? # Other available versions

This works just fine for me.

-- Gerard

If you don't know what game you're playing, don't ask what the score is.

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'; ?>

Quoting Justin McAleer justin@fehuq.com:

A lot of the posts in this thread seem to be debating between version numbering and storage layout, which are not mutually exclusive

Yes, but this only addresses the problem at the source, not at the redistribution point (mirrors, rpm repositories, distributions, etc)

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.

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). 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.

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.

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.

-- Eric Rostetter The Department of Physics The University of Texas at Austin

Go Longhorns!

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 , 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.

On 29/03/2007 03:41, Eric Rostetter wrote:

Quoting John Robinson john.robinson@anonymous.org.uk:

...

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.

Yes, exactly. But they still don't know, or just don't get it. And I'm talking large scale here, not a few people.

Again, their problem, not ours, as Charles Marcus seems (to me) to have pointed out.

...

In a sense, it is; it's certainly not Dovecot's. If <distro> chooses to include version , consumers of <distro> ought to take up any problems with <distro> before they come here.

Yeah, but how likely is that (especially if they use a RHEL clone instead of the real RHEL)?

People like me? Again, if you use a RHEL clone like CentOS, you ought to have read the support details (i.e. this is a free rebuild, you may rely on RH but don't complain to them or us). 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).

If CentOS users come here, they should be ready to be told "don't use that, try the latest, or wait for RHEL to fix theirs and CentOS to follow".

Having said all this, what it probably boils down to is that once we've a release, we (this list) can support 1.0 while we try to contribute to 1.1 (or whatever), but before we've a release it's definitely the responsibility of packagers who decide to make a release to support their packages.

...

Once dovecot's reached 1.0, a sane version numbering system will help put all this to rest.

Problem is, sanity is subjective...

Oh yes, I agree, especially mine :-)

Cheers,

John.

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.

John Robinson wrote:

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.

Come on...

This isn't like you're going to have end-users downloading dovecot to their workstations...

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...

--

Best regards,

Charles

...

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!

Exactly! But seriously - I don't see this as a valid comparison.

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.

But you don't cripple yourself in the process. Accepted best practices should be more than enough 'help' for those who are competent to run their own server.

As for people who dig themselves in a hole due to laziness/ignorance and/or incompetence - well, the people on this list are by far the most courteous I have met when it comes to people asking questions that they would get shot down in flames for if asked on the courier-imap or postfix lists, so anyone who does come asking for help, will simply have their error politely pointed out to them, complete with recommendations on how to remedy their problem, no?

By the way - what is 'ultruism'? At first I thought it was a typo, but you did it twice... ;)

--

Best regards,

Charles

On March 29, 2007 10:13:37 AM -0500 Eric Rostetter rostetter@mail.utexas.edu wrote:

Quoting Charles Marcus CMarcus@Media-Brokers.com:

...

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

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".

-ejay

On Wed, 2007-03-28 at 21:48 +0200, Matthias Andree wrote:

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.