+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 <rcm...@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 > rcm...@gmail.com > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
