lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: Solr NightlyBuild
Date Wed, 20 Sep 2006 21:14:17 GMT

Taking the question of Solr releases in a more philosophical direction...

The more I've gotten involved with Lucene and Solr 9and Apache in general)
the less I've come to think of "Releases" as entites are really all that
beneficial.  The Lucene 1.4.3 -> 1.9 -> 2.0 evolution really helped hit
home some things that were discussed at JavaOne this year about the Java6
release candidate process.  The notion of formal release candidates and
builds carries with it a lot of baggage and a lot of administrative
overhead that frequently just gets in the way ...  it would be just as
easy to view all of hte nightly builds as "releases" with the date
substituting for the version number, and just accepting that some releases
are more significant then others (in terms of changes/features/bugfixes)
and that some releases are more stable then others.

If i recall correctly, the guys from Sun pointed out that *not* having
formal builds / release candidates for Java6 caused the user community to
spend more time looking at the continuous integration snapshots (ie: daily
builds) finding more bugs faster -- from there, certain builds stood out
as having a lot of good features/fixes compared to the builds that came
before them, without having quite as many bugs as some of the builds that
came after them -- and those builds lent themselves nicely to being
treated as "semi-stable release candidates" for people who didn't want to
constantly be on the bleeding edge.

It's easy to imagine a world in which...

  * Solr nightly builds are only generated on days when changes are
    commited, reducing the total number of builds.
  * A permenant archive of all builds is kept (tags would work)
  * As bugs are reported and test cases are written tools could automate
    the process of running those tests against previous builds to better
    identify how long a bug has been arround (ie: only in certian
    versions, since the birth of the feature, etc...)
  * people could "vote" for specific builds indicating their use of that
    build and their opinion that it is stable and contains significant new
    functionality over previous builds.
  * builds with enough "votes" could be retroactively labeled "releases"
    for those who don't want to be on the bleeding edge and only like
    runing code with a "release" label on int
  * releases could automaticly get their own branch for bug fixes, with
    it's own set of continuous integration builds which would be
    considered "patch releases"

...of course, this is just me waxing poetic about the virtues of a system
like this, i'm sure that my naivety blinds me to countless problesm a
system like this might entail, not to mention that i don't know how well
it would like up with the Apache policies on formal release management
(which i know exist, but ave a hard time following since they seem to
change frequently) .. but still, it's nice to day dream now and then


View raw message