IcedTea6 releases

[Andrew John Hughes]

2009/2/23 Andrew Haley <aph at redhat.com>:
> 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.
>

Reusing the same release tree seemed very strange to me as well.  I
have the vain hope that having a release tree might mean we can have
an upstream backport of important things like security fixes.  Hence,
I was thinking along the lines of something like releases/icedtea6/x
trees e.g. releases/icedtea6/1.4.1.

This is especially the case if anyone wants to do a release right now
as the NIO2 stuff isn't ready for release yet, so a branch from 1.4
would be needed.

>> 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.
>

+1

>> 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.
>

I can't see any reason you'd want to feed a release tree back into
trunk.  The usual course of action and the point of a release branch
is to be able to cherry-pick suitable additional patches and apply
them against a known stable base for release.

> Andrew.
>

-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8