IcedTea6 releases

[Mark Wielaard]

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.

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.

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,

Mark