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
