Sounds like you need a feature freeze branch. As for legal issues about letting people know about unofficial builds... it's open source right, so the waiver at the top is pretty explicit.
On Thu, 2008-06-05 at 16:47 -0700, Ryan Grange wrote: > It would be nice to see some kind of update to the Solr website > regarding what's holding up a 1.3 release. I look at that a lot more > often than I look at this mailing list to see whether or not there's a > new version I should be looking to test out. > > Ryan Grange, IT Manager > DollarDays International, LLC > [EMAIL PROTECTED] > 480-922-8155 x106 > > > > Noble Paul ??????? ?????? wrote: > > If a feature that is really big (say distributed search) is half > > baked and not ready for primetime, we must hold on the release till it > > is completely fixed. That is not to say that every possible > > enhancements to that feature must be incorporated before we can do a > > release. If the new changes are not going to break the existing system > > we can go ahead. > > > > A faster release cycle can drive the adoption of a lot of new features > > because users are not very confident of nightly builds and they tend > > to stick with the latest realease available. SolrJ is a very good > > example. So many users still have their own sweet client libraries in > > production because they think SolrJ is yet in development and there is > > no release. > > > > --Noble > > > > On Wed, May 21, 2008 at 11:46 PM, Chris Hostetter > > <[EMAIL PROTECTED]> wrote: > > > >> : 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 > >> > >> > >> > > > > > >
