lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe_schae...@yahoo.com>
Subject Re: [lucy-dev] Apply fixes and release 0.1.1
Date Wed, 06 Jul 2011 01:05:27 GMT
The 0.1 branch merges weren't wasted work for people who need lucy
now but cannot get trunk to build.  I appreciate the effort that
went into it, and think we should keep that branch around for a while,
but if we're going to release new things soon I'd prefer to see us
get feedback on the charmonizer build changes too as those will become
critical again for clownfish once the C migration is complete.

So basically +1 to pressing on to 0.2 at this point.



----- Original Message ----
> From: Marvin Humphrey <marvin@rectangular.com>
> To: lucy-dev@incubator.apache.org
> Sent: Tue, July 5, 2011 8:48:13 PM
> Subject: Re: [lucy-dev] Apply fixes and release 0.1.1
> 
> 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:
> 
>      
>http://incubator.apache.org/lucy/docs/perl/Lucy.html#Backwards-Compatibility-Policy
>
> 
>      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,
>        trunk/example-lang)
> 
> 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:
> 
>      http://www.perlmonks.org/?node_id=912088
> 
>     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
> Leopard.
> 
> 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
> 
> 

Mime
View raw message