8:39 a.m.
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?
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.
Eventually, they have a wider distribution one with a different naming:
1_1_0_SP1 (SP = Service Pack)
And there goes my extra decimal point scheme.
I think CPs after that would go like:
1_1_0_SP1_CP1
as I've also seen then use
1_1_0_GA_CP1 instead of just 1_1_0_CP1
I've also seem ugly things like
1_1_0_PATCH1
What should we do in these cases?
Add non-numerics in the version field and have:
1.1.0.GA
1.1.0.GA.CP1 or 1.1.0.GA_CP1
Or should we create a "post-release" convention, with a numeric field
(non-zero, to distinguish from pre-release tags) followed by the
alphanumeric from upstream, like "GA", "GA_CP1" etc?
Please, think a little bit about this, they have quite a few packages.
Regards to all,
Fernando
P.S.: We don't need the leading '0.' in this case as there won't be a
following pure digit version, like it happens for pre-release tags.
9:29 a.m.
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?
"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. "
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)
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
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)?
~spot
10:04 a.m.
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
--
Nicolas Mailhot
4:24 p.m.
Nicolas Mailhot wrote:
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
Yeah, for me too. The reason is that people are informed that certain
bugs are fixed in (and after) certain post-releases, so they really need
to know which one they have.
> 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
As you brought that up... I saw that some keep the uppercase letters
from the upstream tag or tar ball version, others make it lower case.
What is the correct way?
Fernando
4:28 p.m.
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
4:40 p.m.
On Wed, 2007-03-21 at 17:28 -0400, Fernando Nasser wrote:
> 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'll draft this one up, we'll discuss it during next week's meeting.
~spot
12:58 p.m.
On Wed, Mar 21, 2007 at 09:39:39AM -0400, Fernando Nasser wrote:
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?
The reason for moving part of the version into the release (because in
1.0rc5, "rc5" *is* part of the upstream version) is to cope with rpm's
ordering w/o having to resort to Bad Unnamed Things.
But usually post-release tags are less complicated, they usually
follow a scheme like 1.2.3p1,2,3,4,... or 1.2.3a,b,c,... etc, which
are properly ordered wrt to both the "patchlevel 0" release and the
next upcoming release.
In these simple cases (which make most of the post-release taggings)
I'd say use the full version as is. Less confusing to users and fits
nicely.
If your project goes up and down with the post-releases (rpm-wise)
like 1.0 -> 1.0patch1 -> 1.0a2 then you need to split off part of the
version again and shoot the upstream authors.
--
Axel.Thimm at ATrpms.net
6241
days inactive
6243
days old
packaging@lists.fedoraproject.org
6 comments
4 participants
participants (4)
-
Axel Thimm -
Fernando Nasser -
Nicolas Mailhot -
Tom Callaway