incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Re: [lucy-dev] X.Y.Z version number feasibility
Date Fri, 03 Dec 2010 06:30:18 GMT
On Thu, Dec 02, 2010 at 07:15:10PM -0800, Mattmann, Chris A (388J) wrote:
> Hi Marvin,
> 
> My philosophy:
> 
> 1. Use X.Y version #s, starting from 0.X 
> 2. use .Z when it makes sense (aka patch release to X.Y series, e.g., first
> patch in the series is .1, .2, etc.)

If humans were the only consumers of our version numbers, I think that would
work very well.  Unfortunately, we have to cater to programmatic consumers as
well.

In the Perl world, you *really* don't want $VERSION to vacillate between X.Y
and X.Y.Z.  For comparison purposes, X.Y.Z version numbers get converted to
floating point using a formula that can yield surprising results: for
example, version 1.1 > version 1.2.1:

    1.1    => 1.100000
    1.2.1  => 1.002001

Given these conversion quirks, it's essential that we pick one format for
$VERSION and use it consistently, forever.  (David Golden's exhaustive blog
post does a great job of laying out how screwed up the situation is.)

We also want to be consistent about what we use for META.yml.  The situation
there is arguably even more screwed up, because how to specify version numbers
and compare them isn't defined in the spec.  If we switch up between X.Y and
X.Y.Z, who knows what consumers of META.yml are going to decide when comparing
version numbers.  However, if we use X.Y.Z consistently, I think we can expect
correct ordering -- too many things would break if a programmatic consumer
couldn't even get that much right.

I'm not sure about the tarball names, but nevertheless I think it would be
prudent to be consistent.  And what's the harm?  I looked at the Lucene
release archives: while there was a 1.9 release which used X.Y, the first
releases in the 2.x and 3.x branches use 2.0.0 and 3.0.0 within the file
names.  SpamAssassin, likewise: it's first Apache release was version 3.0.0.

    http://archive.apache.org/dist/lucene/java/
    http://archive.apache.org/dist/spamassassin/

So, for those three contexts ($VERSION, META.yml, archive name), IMO we should
either use X.Y or X.Y.Z exclusively.  I vote for X.Y.Z.

I think the only contexts where we can afford to switch back and forth between
X.Y and X.Y.Z are documentation and informal communication such as email or
press releases.  I will probably myself refer to our first release as 0.1
rather than 0.1.0 on our mailing lists.  However, I lean against using X.Y in
the official documentation when all the programmatic tools are using either
X.Y.Z or a programmatic approximation thereof (either 3 integers or an
extended float).

Maybe other languages have better facilities for dealing with X.Y.Z and X.Y
versions and can compare them consistently and correctly.  But IMO, the fact
that both C and Perl/CPAN have problems suffices to justify the proposed
conventions.  

Does that do a better job of explaining the rationale behind the proposal?

Cheers,

Marvin Humphrey


Mime
View raw message