lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: discussion about release frequency.
Date Fri, 10 Sep 2010 00:06:09 GMT
+1 here too - I'm all for more frequent releases - not sure how much
time I can put behind that release to release, but I'm all for the idea
of it.

- Mark

On 9/9/10 5:54 PM, Michael McCandless wrote:
> +1 to simplify the release process / ReleaseTodo wiki, and +1 to
> release a 3.1, and +1 to do frequent stable releases.
> 
> Having a stable branch gives us that freedom and we should use it!
> 
> Mike
> 
> On Thu, Sep 9, 2010 at 2:41 PM, Robert Muir <rcmuir@gmail.com> wrote:
>> Hello,
>>
>> I would like to open a discussion about release frequency from lucene/solr's
>> 3x branch. I'm not asking for votes or anything, just ideas.
>>
>> For Lucene/Solr its been a pretty long time since the users got a feature
>> release.
>> I don't consider Lucene 3.0 as a feature release either.
>>
>> I think now that we have a "trunk" for unstable development, and a "3x"
>> stable branch, that we should think about cutting releases from this branch
>> much more often, for example every month or two.
>>
>> I think that by doing this, we will engage the community more: because many
>> people won't run svn checkouts/snapshots, and many people probably wont even
>> look at unreleased code.
>>
>> In the past it seems releases were fairly infrequent, and I'm not sure I
>> have the background to really understand why, but i have 3 theories:
>> * concerns about the actual code being stable
>> * the release process is too complicated
>> * getting someone to do the work
>>
>> For stability, my argument is that our "3x" stable branch is inherently more
>> stable than previous trunks were, so its safe to release more often from it.
>> I give some very rough, very unscientific numbers below from Lucene's JIRA,
>> but I think the same applies to Solr.
>>
>> Based on the last 4 weeks of development (resolved issues):
>>
>> Of bugfixes, about half (6) are fixes to bugs that already existed in
>> 2.9/3.0
>> About 25% (3) are fixes to bugs we only introduced in trunk, and do not
>> affect 3x.
>> The other 25% (4) are fixes to things we introduced in trunk/3x
>>
>> You could say this suggests 3x is very roughly "twice" as stable as trunk,
>> yet has about 80% of the new features/improvements (14 out of 17).
>>
>> With regards to the release process: I also think if we decide to do this,
>> we must simplify and automate our release procedures.
>> To be frank, http://wiki.apache.org/lucene-java/ReleaseTodo scares the crap
>> out of me, and something like 'ant release' that someone can run from the
>> top level for both Lucene and Solr would really go a long way towards making
>> the release process less painful. I realize this is difficult and cannot be
>> fully automated but I think it can be improved.
>>
>> Finally, as far as getting someone to do the work, I can certainly volunteer
>> to help in the following ways:
>> * being RM if you are ok with a non-maven release (until LUCENE-2268 is
>> fixed, i am uncomfortable with maven)
>> * improving the build to simplify the release process: (see SOLR-2002 for a
>> start)
>>
>> --
>> Robert Muir
>> rcmuir@gmail.com
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message