On Mon, May 19, 2008 at 2:49 PM, Chris Hostetter <[EMAIL PROTECTED]> wrote: > > : solr release in some time, would it be worth looking at what outstanding > : issues are critical for 1.3 and perhaps pushing some over to 1.4, and > : trying to do a release soon? > > That's what is typically done when the Developers start getting an itch to > make a release. > > Jira keeps track of all the issues that are marked outstanding issues that > have been targed for 1.3... > http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310230&fixfor=12312486 > > ..some of these are major features that are in active development (in some > cases: partially commited) while others are more wishlist items that misc > people have said "it would be really cool to try and do this for 1.3" but > have no patches attached yet. > > If people are particularly eager to see a 1.3 release, the best thing to > do is subscribe to solr-dev and start a dialog there about what issues > people thing are "show stopers" for 1.3 and what assistance the various > people working on those issues can use. > > -Hoss > >
As evidenced in this thread, SOLR users are stratifying into two classes: 'in the know' technical types who run b/leeding edge, and a presumably larger group waiting for formal release. The SOLR system experience is significantly different for these groups. One year between releases is a very long time for such a useful and dynamic system. Are project leaders willing to (re)consider the development process to prioritize improvements/features scope into chunks that can be accomplished in shorter time frames - say 90 days? In my experience, short dev iteration cycles that fix time and vary scope produce better results from all perspectives. Dan
