-let's make progress towards 4.0
Robert Muir 2012-04-25, 13:34
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
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
- 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.
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
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
* 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.