+1 to more frequent releases. I think we are already seeing 3x being pushed forward as the stable version for users wishing to do some development of their own.
I am more than happy to work with whoever on the maven issues as I feel that it is really important to keep making maven releases. Maven does have a release plugin, similar to what you want to build for ant, perhaps that can provide some inspiration? Chris On Fri, Sep 10, 2010 at 12:06 PM, Mark Miller <markrmil...@gmail.com> wrote: > +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 <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 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Chris Male | Software Developer | JTeam BV.| www.jteam.nl
