+1. We've been asked at LR for the last loong time and I agree that if 4.0 is to be release this _year_, we can't let it languish much longer.
On Wed, Apr 25, 2012 at 9:34 AM, Robert Muir <[email protected]> wrote: > Hello, > > As mentioned previously, we've had a lot of unreleased code in trunk > for a few years now: it would be nice to start making progress on 4.0. > The release will already be big and scary and oversized! Its almost > May, so if we don't start working now, I don't think a 4.0 release is > going to happen in 2012. > > Here are a number of things I think we should start tackling: > > * Jira issues: > There are 211 open Lucene, 368 open Solr issues. > To make some progress, can we you please review JIRA issues that you > don't think will get fixed in the near time? > I created "4.1" versions in Lucene/Solr JIRA you can push them back to > already. > Things that need to be release blockers, mark them blockers. Things > that can be in a 4.1, lets just move them to 4.1. > After a few weeks, I think we should then apply a process like Hoss > did for 3.6, where we start moving out unassigned issues > automatically. > > * Documentation: > This is primarily a Lucene problem mostly (I think?). Remember we are > hard-breaking many APIs and there is no Lucene in Action book for > people to refer to. So I think its important to improve the > documentation: > - API documentation and examples: We need to make sure any APIs that > are listed in MIGRATE.txt have good docs, and for stuff like postings > APIs, probably also examples in the package javadocs (e.g. > o.a.l.index). Otherwise nobody will know what to do! > - File Formats Documentation: I've assigned this one, I'll work on > getting it in shape. > - Solr Cloud: As new doc, this is likely in better shape than on the > Lucene side (and its mostly wiki-oriented anyway). But its great if we > can have this looking awesome before release. > > * Packaging: > We should make sure 'ant prepare-release-no-sign' actually makes > binary artifacts that we like. Especially, does it include everything > it should?: e.g. should/is 'cloud-dev' be in the Solr binary package? > If it doesn't have what it should, lets open issues and get it fixed. > > * Release docs: > This is a big release and we should go on the wiki and try to start > organizing some reasonable release notes / high-level summary of the > features. > > * Branching: > At some point we need to create a branch_4x, especially so that Google > Summer of Code students are able to do great and wonderful things in a > 5.x trunk and not in a release branch. We should probably plan to > branch in the next few weeks so that we can actually start stabilizing > code. > > * Alpha preparation: > It seems nobody had any objections previously to what an alpha release > should be: So I still think our guarantee here is only "We won't > change the index format unless necessary to fix a bug". I think it > will take some time for users to actually try this thing no matter > what we do, and for any feedback-bugfix iteration loops. Because of > this I think we need to ensure we have an artificial delay before any > beta release to allow this to happen: we should think about how long > that delay should be... e.g. 1 months? 2 months? Lets figure it out. > > -- > lucidimagination.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
