Chris Hostetter wrote:
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"

FYI, Hadoop makes monthly releases (usually on the first Friday). A branch is started for each release, and, over the next week, if serious bugs are found they're fixed in the branch and a point release is made. So the rule is that any release over a week old is stable. This seems to be working pretty well. New features make it out to folks pretty quickly. We use Jira to generate release notes, by making sure that every commit message references a Jira issue ID. The build process includes the Subversion repository url and the revision in the jar, so that sources for any build can be re-created. Someday we might slow the clock-based release cycle, but I'm generally pleased with it. Releases are not a big deal, we just turn the crank. Deciding if/when to make point releases has not been difficult, in part because folks know that if something doesn't get in the point/bugfix release then it will make it out three weeks later. Contributors frequently mark a patch as something that should not be applied until after the next release, so that it will get a full month's use by developers before it's packaged into a release.

Doug

Reply via email to