Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts

[Timothy Brownawell]

On 11/23/2010 03:17 AM, Richard Levitte wrote:
> In message<address@hidden>  on Mon, 22 Nov 2010 23:13:08 -0600, Timothy 
> Brownawell<address@hidden>  said:
>
> tbrownaw>  On 11/22/2010 10:48 PM, Hendrik Boom wrote:
> tbrownaw>  >  On Mon, Nov 22, 2010 at 11:46:49PM -0500, Hendrik Boom wrote:
> tbrownaw>  >>  On Mon, Nov 22, 2010 at 05:28:23PM -0600, Timothy Brownawell 
> wrote:
> tbrownaw>  >>>  On 11/22/2010 09:43 AM, Hendrik Boom wrote:
> tbrownaw>  >>>>  This if we add ~dev7 to version number 1.1, we'll get version
> tbrownaw>  >>>>  1.1~dev7,
> tbrownaw>  >>>>  which will sort before version 1.1
> tbrownaw>  >>>>
> tbrownaw>  >>>>  This sounds like the numbering system we're looking for.
> tbrownaw>  >>>>
> tbrownaw>  >>>>  Of course, this isn't the *entire* comparison alrorithm. 
> There's also
> tbrownaw>  >>>>  an epoch and a Debian-specific attachment to the verison 
> number.
> tbrownaw>  >>>>  Check
> tbrownaw>  >>>>  the link above for further details.
> tbrownaw>  >>>
> tbrownaw>  >>>  Yep, that would be ideal except it looks like rpm-based distros 
> don't
> tbrownaw>  >>>  support it.
> tbrownaw>  >>
> tbrownaw>  >>  Maybe we should log a bug against rpm itself.
> tbrownaw>  >
> tbrownaw>  >  Maybe we should first find out what the actual specifications are 
> for
> tbrownaw>  >  version numbers in rpm.
> tbrownaw>
> tbrownaw>  
> http://rpm.org/gitweb?p=rpm.git;a=blob_plain;f=lib/rpmvercmp.c;hb=HEAD
> tbrownaw>
> tbrownaw>  Numeric segments are newer then alpha segments, anything other than 
> an
> tbrownaw>  alnum is a separator and is otherwise ignored. So "abc123.de-~f8g" 
> has
> tbrownaw>  segments "abc" (alpha), "123" (numeric), "de" (alpha), "f" (alpha),
> tbrownaw>  "8" (numeric), "g" (alpha). I also found a perl module earlier today
> tbrownaw>  that claimed to have copied an earlier rpm version; that had alpha
> tbrownaw>  vs. numeric segments in the same position as arbitrary/undefined but
> tbrownaw>  was otherwise the same.
>
> How does the algorithm compare when one of the version has a segment
> empty and the other doesn't in corresponding positions?  To take a
> current example, how does 0.99 (segments "0" and "99") compare with
> 0.99.1 (segments "0", "99" and "1") according to those algorithms?
> How would 0.99 compare with 0.99dev (segments "0", "99" and "1")?
>
> My personally interpretation would be that 0.99dev would be older than
> 0.99, which would be older than 0.99.1, so as "value" goes, the empty
> segment would be newer than a alpha segment but be older than a
> numeric segment...

0.99      => 0 99
0.99dev   => 0 99 "dev"
0.99.1    => 0 99 1
0.99~dev  => 0 99 "dev"

first all have a number zero, which are equal. Next they all have a 
number 99 which are also equal. For the last segment we have (blank) vs 
string "dev" vs number 1. On "dev" vs 1, "dev" will be older and 1 will 
be newer. On (blank) vs. either... it will hit the break near the top 
and then at the end the "whichever version still has characters left 
over wins", so (blank) will sort first. So it would be in order
   0.99
   0.99dev and 0.99~dev (these are indistinguishable)
   0.99.1

Also from IRC we have:
   <thm_> the whole release numbering discussion is not meaningful wrt
   rpm, as Fedora for example has its own rules, forbidding
   non-numerics in the version part of an rpm.

So what's left is either even/odd to indicate release/dev, or .90/.99 to 
indicate dev.

Option 1
   1.0 or 1.0.0, 1.0.1, 1.0.2 <- release
   1.1                        <- dev
   ???                        <- RC
   1.2, 1.2.1, ...            <- release

Option 2
   1.0, 1.0.1, 1.0.2, ...     <- release
   1.0.90                     <- dev
   1.0.91, 1.0.92             <- RC
   1.1, 1.1.1, 1.1.2, ...     <- release


--
Timothy

Free public monotone hosting: http://mtn-host.prjek.net