IcedTea6 releases

[Lillian Angel]

Hi,

Andrew John Hughes wrote:
> 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.
>   


I agree with this. Having a separate release tree for every release. It 
could initially be created as an exact copy of the main tree (or some 
tagged version), and appropriate patches could be applied or added. For 
minor releases, the differences between the main tree and the release 
tree could be significant. I think for major releases, the main tree 
should always be tagged as 1.x once the release tree is created.

I may be completely off target. But what are everyone's thoughts on 
tagging the main tree after a release?

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


Lillian