The Solr website isn't really for disseminating that information
(also, we aren't allowed to advertise unofficial builds very loudly.
It's a legal thing.).
If you want to know what is holding up release, check out JIRA:
<http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310230&fixfor=12312486
>
-Mike
On 5-Jun-08, at 4:47 PM, 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
