IcedTea6 releases

[Andrew Haley]

Mark Wielaard wrote:
> Hi,
> 
> One of the things we discussed at Fosdem was how to coordinate releases.
> We agreed that in principle everybody should be able to "call a
> release", at least for IcedTea6. In principle that tree should always be
> in releasable state. That said, it is still a good idea to have a
> stabilization period, where no new features are added, and only
> (regression) fixes are done. But this also shouldn't block all other
> work.
> 
> So to help with that we thought it would be a good idea to have a
> separate "release tree". We tried in-tree-branches, the cacao work was
> for a time an in-tree branch, but that wasn't a complete success.
> 
> So for now we wanted to go with a separate repo that someone can "claim"
> when doing the release. They will then be responsible for updating the
> release tree to the current icedtea6 tree, call for test results, merge
> in any needed regression fixes, tag and finally release.

Sure, but there's no need to re-use the same release tree.  Once the
release is done, further bug fixes may be needed against the same
release, so a release tree should never be re-used.

> Finally the release tree should be merged to the main icedtea6 tree to
> make sure that they are in sync again, tags are propagated to the main
> tree, etc. and the whole process can start from the top.

I think that in most cases bug fixes go in the other direction: they are
committed to trunk and to live release branches.  The only exception to
this is normally when a patch is inappropriate.

> The above assumes that all releases will be linear progressions from the
> current IcedTea6 tree. No "minor" releases from a previous major
> release, while we also do a new "major" release (IcedTea7 will be for
> the really crazy stuff anyway). I think this will work out for IcedTea6
> because in principle there will only be new features and bug fixes (the
> disappearance and reappearance of visualvm might be an exception
> though). If however we want to do backward, minor releases, then we
> might just have to create either another release tree.
> 
> I created a "release tree" as releases/icedtea6
> ssh://icedtea.classpath.org/hg/release/icedtea6 or
> http://icedtea.classpath.org/hg/release/icedtea6
> 
> This tree will not generate commit messages, but syncing it back with
> the main tree will, so you can easily see which bug fixes and tags were
> added during the release process. I don't believe extra commit messages
> are necessary for this tree because the "release master" will be the
> only person responsible for doing commits to this tree during the cycle.
> 
> Comments, suggestions and friendly flames welcome,

The above is all wrong.  If we're to make such a radical departure from
well-established practice we have to have a damn good reason.  AFAIK
there is no such reason, so we must not do this.

Andrew.