lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <>
Subject Re: [lucy-dev] X.Y.Z version number feasibility
Date Fri, 03 Dec 2010 16:36:19 GMT
Hi Marvin,

Err, umm, ok. I'm not sure how the long explanation below tells me how progammatic use version
#s using my suggestion are any more difficult. In addition, you mention Perl as a counterexample
where there would be a problem, but don't mention C, yet later on you refer to Perl and C
interchangeably as problem languages. In addition when I've asked in the past I've heard pretty
vehemently that Lucy is a C API first, but with dynamic bindings, etc., but *second*. So,
why are we engineering around a secondary concern? 

What's the legitimate concern here with using my suggestion with C (Lucy's primary API AIIU)?

Furthermore, it seems that some of this stuff (at least in Perl) can be obviated by *not*
using the > operator to compare versions. To be honest, I've never liked that in Perl/CPAN,
nor have I in PHP/PEAR, where it's also used quite extensively. I prefer *explicit* version
numbers like what you see in Maven or Ivy, which really gets around this type of problem.


On Dec 2, 2010, at 10:30 PM, Marvin Humphrey wrote:

> 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.
> 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

Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA

View raw message