lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: [lucy-dev] Apply fixes and release 0.1.1
Date Wed, 06 Jul 2011 00:48:13 GMT
On Fri, Jul 01, 2011 at 09:52:37AM -0700, Chris Hostetter wrote:
> My only question from the peanut gallery would be "why 0.1.1? why not just 
> roll out 0.2?"

That's an interesting proposition.

> I understand the fundemental value in bug fix point releases, but Lucy is 
> still a very young project, I can't imagine thta API/feature stability and 
> back compat is a that big of an issue yet.

We have a "Backwards Compatibility Policy" in place which works around the
lack of module versioning and deprecation support in Perl/CPAN etc. and will
allow us to continue evolving the API:

    Backwards Compatibility Policy

    Lucy will spin off stable forks into new namespaces periodically. The
    first will be named "Lucy1". Users who require strong backwards
    compatibility should use a stable fork.

    The main namespace, "Lucy", is an API-unstable development branch (as
    hinted at by its 0.x.x version number). Superficial interface changes
    happen frequently. Hard file format compatibility breaks which require
    reindexing are rare, as we generally try to provide continuity across
    multiple releases, but we reserve the right to make such changes.

So, any rationales that apply to 0.1.1 vs. 0.2.0 because Lucy is a "young
project" will continue to apply against future releases.

> Are any changes on trunk so radical that any of the existing 0.1 users 
> who might upgrade to 0.1.1 wouldn't upgrade to 0.2?

There are no new features on trunk.  IIRC, only build system stuff has changed
since Chris Mattmann forked off the 0.1 branch in late May as part of the
0.1.0 release process.  The changes since then fall into four categories:

    * Portability bugfixes.
    * Charmonizer build system changes.
    * Porting the Clownfish Compiler to C.
    * Nascent efforts to add new host languages.  (trunk/ruby/Rakefile,

Only the portability bugfixes have been merged to the 0.1 branch.  So
releasing 0.2.0 instead of 0.1.1 would mean adding the Charmonizer Makefile
changes, my in-progress efforts to port the stuff under trunk/clownfish to
C, and some binding language stuff which isn't really ready for people to look
at yet.

I'd been thinking about proposing to release 0.2.0 once the port of the
Clownfish compiler to C was complete and Parse::RecDescent eliminated as a
dependency.  But we can bump that back to a future release.

I think what this comes down to is whether the additional material has
problems that would interfere with our fixes.  Up until last Saturday, the
Charmonizer Makefile stuff still had portability glitches, but I think it's
pretty good now.

> The bug fix changes list you are proposing seem entirely related to 
> build/run protability, which means anyone who was bit by those trying to 
> install 0.1 probably isn't running lucy at all becaues of it (correct?) so 
> if they upgrade they won't really care if it's 0.1.1 or 0.2. 

That's right.  If we release 0.1.1 right now, there's no reason for anyone who
has successfully installed 0.1.0 to upgrade -- but then, the same would hold
true for upgrading from 0.1.0 to 0.2.0.

Nevertheless, it would be nice to get out a release with the portability
bugfixes one way or another, as our lack of Windows compatibility has been
causing problems:

    Problem installing Apache Lucy

    Hi, I need to install Apache Lucy, so I tried from Cpan using the command
    "install Lucy", but it fails: "Make had returned bad status...".
    So I tried to make it, and: "Could not make: Unknown error". 

> LIkewise anyone who's running 0.1 fine won't have any reason to upgrade if
> you put out a 0.1.1 (because if it's working for them on their OS those bug
> fixes probably don't affect them) ... but they might be interested in
> upgrading to 0.2 if it's also got new features.

I've tested both trunk and the 0.1 branch recently and they both build and
test clean on my three Windows setups and on my MacBook Pro running Snow

I guess I lean towards cancelling the 0.1.1 release and going with 0.2.0
instead because it would be good to start burning in the updated build code,
and it's not worth it to merge all the stuff that Joe and I have been doing
over to the 0.1 branch.

That would make the transition from 0.2.0 to 0.3.0 less churnful than the
transition from 0.1.1 -> 0.2.0 was going to be, which is a good thing.

Does anybody else have opinions on the matter?

Marvin Humphrey

View raw message