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 17:35:35 GMT
On Fri, Dec 03, 2010 at 08:36:19AM -0800, Mattmann, Chris A (388J) wrote:
> 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. 

I mentioned C as a problem because it has no native type which supports X.Y.Z
version numbers.  Instead many projects use multiple integers, as we might:

    #define LUCY_VERSION_MAJOR 0
    #define LUCY_VERSION_MINOR 1
    #define LUCY_VERSION_MICRO 0

Perl ostensibly has native support for X.Y.Z version numbers, but within the
language itself, the support is messed up enough that it's better to use a
specicially crafted floating point variant.

The situations are similar: neither C nor Perl provides an elegant way to
express X.Y.Z version numbers programmatically.  So in our documentation, we
continue to describe our releases in the X.Y.Z terms that humans find most
intuitive, but in code, we express version numbers using techniques ginned up
for each language.  

Other host languages will present similar problems; we'll have to gin up
solutions for them as well.

> Furthermore, it seems that some of this stuff (at least in Perl) can be
> obviated by *not* using the > operator to compare versions. 

We don't have control over that; it happens in user code.  Most notably, it
happens in automated tools such as CPAN when they try to determine which one
of two release archives has a higher version number.  We don't want those
comparisons to get messed up!

But it also happens in end user code.  In Perl, this snippet means "load Lucy
0.2.0 or greater"...

    use Lucy 0.2.0;
    
... and thus requires fetching $Lucy::VERSION and comparing against the
requested version number.  We can't stop people from writing that.

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

I'm only familiar with those systems by reputation, so I can't speak about
them authoritatively.  However, I assume that using X.Y.Z version numbers
consistently for our Lucy releases isn't going to throw Maven or Ivy for a
loop. 

Using a mixture of X.Y and X.Y.Z *will* throw Perl/CPAN for a loop, though.
Going with X.Y.Z consistently seems like a minor compromise to accommodate
that host target.  Especially since other Apache projects do just that!

Please understand, I *like* your proposal slightly more using X.Y.Z
consistently, and I like it better than the X.Y version numbering used up till
now with KinoSearch.  I've just invested a bunch of time researching how we
can move as close as possible to it.  Personally, I'm pretty happy with the
fruits of that research and where we've ended up.  It seems pretty darn close
to your preferences to me, and I hope that the remaining distance isn't enough
to make you unhappy.

Cheers,

Marvin Humphrey


Mime
View raw message