Le Mer 21 mars 2007 15:29, Tom "spot" Callaway a écrit :

I prefer option 1, as I suspect that users might care when something is in beta/pre-release,

IMHO option 2 is better

but don't care at all about post-release levels as long as it works. Either way works. The latter mechanism is a logical extension of CVS/SVN release naming,

And is good for the same reason pre-release is (stop users complaining because they don't understand the actual version used)

but it introduces icky underscores and makes the n-v-r longer (for what benefit)?

There's no reason not to sanitize alphatags, using small caps and replacing underscores with something else (nothing, dot, whatever). Alphatags are informative

Hi Tom,

Tom "spot" Callaway wrote:

On Wed, 2007-03-21 at 09:39 -0400, Fernando Nasser wrote:

...

Hi all,

We have for quite some time figured out what to do with pre-release tags: 0.#.<tag>.#%{?dist}

But what to do with _post_-release tags?

...

From http://fedoraproject.org/wiki/Packaging/NamingGuidelines

"Post-release packages: Packages released after a "final" version. This usually is due to a quick bugfix release, such as openssl-0.9.6b or gkrellm-2.1.7a. In this case, the non-numeric characters are permitted in the Version: field. "

Yeah, I saw that. It did not bother me while these thing were a single letter like 'a' of 'b'. But when things start becomeing strings like SP1_CP2 or GA_CP1 it made me wish to have them out of the version part.

...

Here is an example:

These upstream software releases its software from pre-release to final like that:

1_1_0_BETA 1_1_0_BETA1 1_1_0_BETA2 1_1_0_CR1 1_1_0_CR2 1_1_0_GA

So far so good, we use pre-release tags for all but the last, which we call just '1.1.0'.

After the final release (GA- General Availability), the process goes on. After some fixes are added, they release:

1_1_0_CP1 1_1_0_CP2 1_1_0_CP3

So I thought we could just add one decimal point: .1, .2 and .3 for the above.

Two methods come to mind:

1. Just increment the release and ignore the post release tagging, e.g.

foo-1.1.0-0.1.BETA foo-1.1.0-0.2.BETA1 foo-1.1.0-0.3.BETA2 foo-1.1.0-0.4.CR1 foo-1.1.0-0.5.CR2 foo-1.1.0-1 (is actually GA) foo-1.1.0-2 (is actually CP1) foo-1.1.0-3 (is actually CP2) foo-1.1.0-4 (is actually CP3) foo-1.1.0-5 (is actually SP1) foo-1.1.0-6 (is actually SP1_CP1)

The post-release information is important to the users, as it relates to where bugs were fixed.

2. Use the post release tag like a CVS/SVN checkout tag:

foo-1.1.0-0.1.BETA foo-1.1.0-0.2.BETA1 foo-1.1.0-0.3.BETA2 foo-1.1.0-0.4.CR1 foo-1.1.0-0.5.CR2 foo-1.1.0-1 (is actually GA) foo-1.1.0-2.CP1 foo-1.1.0-3.CP2 foo-1.1.0-4.CP3 foo-1.1.0-5.SP1 foo-1.1.0-6.SP1_CP1

This one works.

I prefer option 1, as I suspect that users might care when something is in beta/pre-release, but don't care at all about post-release levels as long as it works. Either way works. The latter mechanism is a logical extension of CVS/SVN release naming, but it introduces icky underscores and makes the n-v-r longer (for what benefit)?

Yeah, the underscore is a drag, but at least it is in the same situation as the ones from CVS tags.

Cheers, Fernando