Re: Solr NightlyBuild

[Clay Webster <we...@gmail.com>]

Hoss,

I really like the idea of having and showing votes for nightlys.  If the
+1/0/-1 was visible
with brief comments and referenced with the changelog .... *wham*, a new
class
of releasing code.  Hell maybe tie in results from unit tests.

Of course you can only do away with official releases so far.  You'll still
will have
api versioning.

--cw

On 9/20/06, Chris Hostetter <ho...@fucit.org> wrote:
>
>
> 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
>
>
>
>
> -Hoss
>
>