Thread: RPM upgrade caveats going from a beta version to RC

RPM upgrade caveats going from a beta version to RC

From
Lamar Owen
Date:
One quick note -- since 'R' < 'b', the RC RPM's must be forced to
install with --oldpackage, as RPM does a simple strcmp of version
numbers -- 7.1RC3 < 7.1beta1, for instance.  Just force it with
--oldpackage if you have a 7.1beta RPM already installed.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


Re: RPM upgrade caveats going from a beta version to RC

From
The Hermit Hacker
Date:
On Sat, 7 Apr 2001, Lamar Owen wrote:

> One quick note -- since 'R' < 'b', the RC RPM's must be forced to
> install with --oldpackage, as RPM does a simple strcmp of version
> numbers -- 7.1RC3 < 7.1beta1, for instance.  Just force it with
> --oldpackage if you have a 7.1beta RPM already installed.

Huh?  I always thought that ASCII R was greater then b ... *confused*  in
the future, would it help to have 7.2Beta?  Or am I missing something? :)




Re: RPM upgrade caveats going from a beta version to RC

From
"Oliver Elphick"
Date:
The Hermit Hacker wrote: >On Sat, 7 Apr 2001, Lamar Owen wrote: > >> One quick note -- since 'R' < 'b', the RC RPM's
mustbe forced to >> install with --oldpackage, as RPM does a simple strcmp of version >> numbers -- 7.1RC3 < 7.1beta1,
forinstance.  Just force it with >> --oldpackage if you have a 7.1beta RPM already installed. > >Huh?  I always thought
thatASCII R was greater then b ... *confused*  in >the future, would it help to have 7.2Beta?  Or am I missing
something?:)
 

R = 82
b = 98

so b comes after R, and `blank' comes before either!

Therefore 7.1 < 7.1RC < 7.1beta !

As I suggested in another mail, let us switch to using even minor
numbers for releases and odd ones for development:

That means the final release of 7.1 will be called 7.2.  Bugfix releases
will then be 7.2.x.  Meanwhile new development versions will be 7.3.x
which will finally be released as 7.4, and so on...

For current 7.1, the Debian releases are 7.1beta, 7.1cRC, 7.1final,
which is both cumbersome and confusing to those who are looking for
an exact match.

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
========================================   "Do not be anxious about anything, but in everything,       by prayer and
supplication,with thanksgiving, present     your requests to God. And the peace of God, which       transcends all
understanding,will guard your hearts       and your minds in Christ Jesus."   Philippians 4:6,7  
 




Re: RPM upgrade caveats going from a beta version to RC

From
Peter Eisentraut
Date:
The Hermit Hacker writes:

> On Sat, 7 Apr 2001, Lamar Owen wrote:
>
> > One quick note -- since 'R' < 'b', the RC RPM's must be forced to
> > install with --oldpackage, as RPM does a simple strcmp of version
> > numbers -- 7.1RC3 < 7.1beta1, for instance.  Just force it with
> > --oldpackage if you have a 7.1beta RPM already installed.
>
> Huh?  I always thought that ASCII R was greater then b ... *confused*  in
> the future, would it help to have 7.2Beta?  Or am I missing something? :)

How about 7.2rc1, which is greater than 7.2beta1.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



Re: RPM upgrade caveats going from a beta version to RC

From
The Hermit Hacker
Date:
On Sun, 8 Apr 2001, Oliver Elphick wrote:

> The Hermit Hacker wrote:
>   >On Sat, 7 Apr 2001, Lamar Owen wrote:
>   >
>   >> One quick note -- since 'R' < 'b', the RC RPM's must be forced to
>   >> install with --oldpackage, as RPM does a simple strcmp of version
>   >> numbers -- 7.1RC3 < 7.1beta1, for instance.  Just force it with
>   >> --oldpackage if you have a 7.1beta RPM already installed.
>   >
>   >Huh?  I always thought that ASCII R was greater then b ... *confused*  in
>   >the future, would it help to have 7.2Beta?  Or am I missing something? :)
>
> R = 82
> b = 98
>
> so b comes after R, and `blank' comes before either!
>
> Therefore 7.1 < 7.1RC < 7.1beta !
>
> As I suggested in another mail, let us switch to using even minor
> numbers for releases and odd ones for development:
>
> That means the final release of 7.1 will be called 7.2.  Bugfix releases
> will then be 7.2.x.  Meanwhile new development versions will be 7.3.x
> which will finally be released as 7.4, and so on...

Not in this life time ... we are not going to move to a Linux-like
development cycle ... *groan*



Re: RPM upgrade caveats going from a beta version to RC

From
"Oliver Elphick"
Date:
The Hermit Hacker wrote:or development: >> >> That means the final release of 7.1 will be called 7.2.  Bugfix releases
>>will then be 7.2.x.  Meanwhile new development versions will be 7.3.x >> which will finally be released as 7.4, and
soon... > >Not in this life time ... we are not going to move to a Linux-like >development cycle ... *groan* >
 

Harrumph!!

Well, pick some scheme that gives a rational set of numbers for
distributions.  The current one is only good for installation
by hand!

(Mind you, my other major package is progressing from -1.00 to 0,
so that -0.76 is followed by -0.75.  Not that I recommend you to 
follow _that_ example.)

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
========================================   "Do not be anxious about anything, but in everything,       by prayer and
supplication,with thanksgiving, present     your requests to God. And the peace of God, which       transcends all
understanding,will guard your hearts       and your minds in Christ Jesus."   Philippians 4:6,7  
 




Re: RPM upgrade caveats going from a beta version to RC

From
The Hermit Hacker
Date:
On Sun, 8 Apr 2001, Oliver Elphick wrote:

> The Hermit Hacker wrote:or development:
>   >>
>   >> That means the final release of 7.1 will be called 7.2.  Bugfix releases
>   >> will then be 7.2.x.  Meanwhile new development versions will be 7.3.x
>   >> which will finally be released as 7.4, and so on...
>   >
>   >Not in this life time ... we are not going to move to a Linux-like
>   >development cycle ... *groan*
>   >
>
> Harrumph!!
>
> Well, pick some scheme that gives a rational set of numbers for
> distributions.  The current one is only good for installation by hand!

We do, we follow the scheme as used by ... the BSD camp :)  Be thankful we
don't go all the way and use 7.2-RELEASE too :)




Re: RPM upgrade caveats going from a beta version to RC

From
Lamar Owen
Date:
The Hermit Hacker wrote:
> We do, we follow the scheme as used by ... the BSD camp :)  Be thankful we
> don't go all the way and use 7.2-RELEASE too :)

If we had 7.1-CURRENT, 7.1-RELEASE, and 7.1-STABLE, the versioning
comparision would be just fine -- better than now.  As it stands, an
upgrade from 7.1beta6 to 7.1RC4 and from 7.1RC4 to 7.1 is in the eyes of
at least two packaging systems a downgrade.

However, 7.1beta6 to 7.1rc4 to 7.1.0 would be an ok progression, as 7.1
< 7.1.0, I think (saying that without having tested it could be
dangerous.... :-)).

Although I must observe that if RPM used the system's locale in
determining version collation, 7.1RC4 would be greater than 7.1beta6 --
which collation breaks our indexing and our LIKE optimizations, and
breaks our regression tests. :-)  But 7.1 would still be a downgrade
based on that.

Red Hat uses a different system for their betas -- which I'm not
necessarily advocating, just presenting:

The public RedHat beta, IIRC, for what may or may not become Red Hat 7.1
carried a version of 7.0.91.

But then again the Linux kernel did that as well, going from 0.13 or so
to 0.97 (and various pl numbers) before hitting 1.0.

And just _why_ are you so adversarial to the Linux version numbering? 
After all, it's just another system..... (Rhetorical question -- I
already know the answer) :-)

Personally, I think the Linux versioning is overkill, and prefer the BSD
way of labeling versions.  But that is just my personal opinion.

But even at that, the Linux and BSD versioning is designed more for
carrying concurrent STABLE and CURRENT versions -- we don't really have
_that_ much version overlap to deal with, do we?  Debian does as much --
but it is again a matter of version concurrency -- we're not likely to
release a 7.1.0 then a 7.0.4 that fixes bugs in the STABLE branch,
whereas at one point Linux 2.0.39, a 2.2.x, and 2.4.0 were being
released concurrently.  The same happens with FreeBSDand others -- but
not us.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


Re: RPM upgrade caveats going from a beta version to RC

From
Alessio Bragadini
Date:
Oliver Elphick wrote:

> R = 82
> b = 98

This is a very small problem of having capital R and lowercase b that I
believe can be taken into account in the development of 7.2.

> As I suggested in another mail, let us switch to using even minor
> numbers for releases and odd ones for development:

It's a Linux-ism that personally I don't like. You have to be familiar
with the project to understand that 8.3.3 is not better for general use
than 8.2.4 because 8.2 is "stable" and 8.3 is "development".

-- 
Alessio F. Bragadini        alessio@albourne.com
APL Financial Services        http://village.albourne.com
Nicosia, Cyprus             phone: +357-2-755750

"It is more complicated than you think"    -- The Eighth Networking Truth from RFC 1925


Re: RPM upgrade caveats going from a beta version to RC

From
Peter Eisentraut
Date:
Lamar Owen writes:

> One quick note -- since 'R' < 'b', the RC RPM's must be forced to
> install with --oldpackage, as RPM does a simple strcmp of version
> numbers -- 7.1RC3 < 7.1beta1, for instance.  Just force it with
> --oldpackage if you have a 7.1beta RPM already installed.

Btw., are you aware of the 'serial' tag to override the version guessing
mechanism?

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



Re: RPM upgrade caveats going from a beta version to RC

From
Lamar Owen
Date:
Peter Eisentraut wrote:
> 
> Lamar Owen writes:
> 
> > One quick note -- since 'R' < 'b', the RC RPM's must be forced to
> > install with --oldpackage, as RPM does a simple strcmp of version
> > numbers -- 7.1RC3 < 7.1beta1, for instance.  Just force it with
> > --oldpackage if you have a 7.1beta RPM already installed.
> 
> Btw., are you aware of the 'serial' tag to override the version guessing
> mechanism?

Yes, I am, actually.  But it seems a broken way of dealing with it. 
Although I do have another idea, thanks to Trond. Rather than package
'7.1RC4-1' I could package '7.1-0.1RC4' -- giving a straight
versioning.  I could progress from '7.1-0.1beta1.1' through
'7.1-0.1beta6.2' through '7.1-0.2RC1.1' to '7.1-1'.

Last time I looked at the documentation for the serial tag, its use was
strongly discouraged.  But that _has_ been awhile -- maybe it could be
useful. But I would prefer the whole version numbering thingtobe fixed,
as the Debian packages have the same issue -- and I don't know if .deb
has an analog to Serial:.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


Re: RPM upgrade caveats going from a beta version to RC

From
"Oliver Elphick"
Date:
Lamar Owen wrote: >Last time I looked at the documentation for the serial tag, its use was >strongly discouraged.  But
that_has_ been awhile -- maybe it could be >useful. But I would prefer the whole version numbering thingtobe fixed, >as
theDebian packages have the same issue -- and I don't know if .deb >has an analog to Serial:.
 

We have epochs, that is, the package version is preceded by an integer
and a colon, which overrides every other part of the version and release
number.  However, if I ever use an epoch, I will be stuck with epochs for ever;
so I don't want to start.

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
========================================   "Is any one of you in trouble? He should pray. Is     anyone happy? Let him
singsongs of praise. Is any one     of you sick? He should call the elders of the church     to pray over him...The
prayerof a righteous man is     powerful and effective."         James 5:13,14,16 
 




Re: RPM upgrade caveats going from a beta version to RC

From
Lamar Owen
Date:
Oliver Elphick wrote:
> Lamar Owen wrote:
>   >as the Debian packages have the same issue -- and I don't know if .deb
>   >has an analog to Serial:.
> We have epochs, that is, the package version is preceded by an integer
> and a colon, which overrides every other part of the version and release
> number.  However, if I ever use an epoch, I will be stuck with epochs for ever;
> so I don't want to start.

RPM also has the epoch mechanism -- and it sounds just like what you
have just described. Not something I want to start using, either. It's
more like a 'super-major' version number than the RPM serial mechanism,
which works in a more broken fashion.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


Re: RPM upgrade caveats going from a beta version to RC

From
Peter Eisentraut
Date:
Lamar Owen writes:

> Yes, I am, actually.  But it seems a broken way of dealing with it.
> Although I do have another idea, thanks to Trond. Rather than package
> '7.1RC4-1' I could package '7.1-0.1RC4' -- giving a straight
> versioning.  I could progress from '7.1-0.1beta1.1' through
> '7.1-0.1beta6.2' through '7.1-0.2RC1.1' to '7.1-1'.

Just name them

7.1betax
7.1rcx
7.1.0
7.1.1
etc.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



Re: RPM upgrade caveats going from a beta version to RC

From
Lamar Owen
Date:
Peter Eisentraut wrote:
> Lamar Owen writes:
> > Yes, I am, actually.  But it seems a broken way of dealing with it.
> > Although I do have another idea, thanks to Trond. Rather than package
> > '7.1RC4-1' I could package '7.1-0.1RC4' -- giving a straight
> > versioning.  I could progress from '7.1-0.1beta1.1' through
> > '7.1-0.1beta6.2' through '7.1-0.2RC1.1' to '7.1-1'.

> Just name them

> 7.1betax
> 7.1rcx
> 7.1.0
> 7.1.1

And I like that -- but that would be Marc's (and the core group)
decision to make not mine. If the current schema is continued, I can
work around it --but it would be nice if the version numbering could be
more packager-friendly.  I have a real aversion to naming the RPM
version number differently from the main package version.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


Re: RPM upgrade caveats going from a beta version to RC

From
"Len Morgan"
Date:
>> Lamar Owen writes:
>>
>> > One quick note -- since 'R' < 'b', the RC RPM's must be forced to
>> > install with --oldpackage, as RPM does a simple strcmp of version
>> > numbers -- 7.1RC3 < 7.1beta1, for instance.  Just force it with
>> > --oldpackage if you have a 7.1beta RPM already installed.

Couldn't this be fixed (in future releases)  with rcX and BetaX?  I believe
r > B.

len morgan



Re: RPM upgrade caveats going from a beta version to RC

From
"Oliver Elphick"
Date:
"Len Morgan" wrote: >>> Lamar Owen writes: >>> >>> > One quick note -- since 'R' < 'b', the RC RPM's must be forced to
>>>> install with --oldpackage, as RPM does a simple strcmp of version >>> > numbers -- 7.1RC3 < 7.1beta1, for
instance. Just force it with >>> > --oldpackage if you have a 7.1beta RPM already installed. > >Couldn't this be fixed
(infuture releases)  with rcX and BetaX?  I believe >r > B.
 

or, for that matter, by betaX rcX.  But we have still gone from rc4 to
nothing in the just-released 7.1, which is backward as far as packaging
systems are concerned.

$ dpkg --compare-versions 7.1 gt 7.1rc4 || echo BSD style does not work!
BSD style does not work!


Marc, _please_ make the next release greater than its betas!

As far as Debian is concerned, 7.1 will be known as 7.1release. Sigh...

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
========================================   "Be strong, and let your heart take courage, all you      who hope in the
Lord."  Psalm 31:24