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 <[EMAIL PROTECTED]> 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
