Version comparison semantics (was: [rfc] six-month stable release cycles)

[Martin Pool]

2009/8/5 Ben Finney <ben+bazaar at benfinney.id.au>:
> Daniel Clemente <dcl441-bugs at yahoo.com> writes:
>
>> El dt, ago 04 2009 a les 12:09, Matthew D. Fuller va escriure:
>> > This can cause ordering problems with tools. Packaging systems may
>> > well be of the opinion that "3.5M1" is 'newer' than "3.5".
>>
>> And also with people. Most people won't know what that M means. 3.5M1
>> looks similar to 3.5.1 when you don't understand the M.
>
> Right.
>
> I'm firmly of the opinion that it's far simpler (technically) *and* far
> better communication to simply have the version string monotonically
> increasing, with normal alphanumeric sequencing.
>
> Don't make me guess (or, worse, keep remembering how your project
> differs from various others) what order “3.5”, “3.5.1”, “3.5a3”,
> “3.5a3dev2”, “3.5rc4”, “3.5rc4pre1”, “3.5m2”, etc. should go in. Make
> each version string *obvious* in its comparison semantics by avoiding
> any special tokens that break the ordering.

That seems like an argument for using 2.90 2.91 3.0 3.0.1 etc, which
easily compare as tuples of integers.  However, we already discussed
that and it's unclear.

Python defines standard semantics for (1, 17, 0, 'beta', 1) and it's
easily accommodated by dpkg, rpm, etc, and people know how to read it.

-- 
Martin <http://launchpad.net/~mbp/>