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. Thanks, Chris 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. > > 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 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
