: 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.
I'm all in favor of shorter release cycles ... but not everything can be broken down into chunks that can be implmeneted in a small time frame, and even if they can, you don't always know that the solution to "chunk1" is leading down the right path. Solr 9and hte Lucene community as a whole) has a long history and deep "cultural" believe in aggressive backwards compatibility .. there is a lot of resistence to the idea of a release that includes the first "chunk" of a larger feature without a strong confidence that the API provided by that chunk is something people are willing to maintain for a long time. At the ned of the day, hat gets people motivated to do a release is discussions on solr-dev where someone says: "i think we need ot have a rlease, and i'm willing to be the release manager. i think we should hold of on committing patches X,Y, and Z because they don't seem ready for prime time yet, and i think we should move forward on trying to commit patches A, B, and C because they seem close to done. what does everybody else think?" -Hoss
