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]
