Hi, sorry, I've been away from the list. Thanks for expanding on this and yes I guess we don't want to *rely* on non-committers in order that we can close off JIRAs. Getting their feedback is of course useful.
I'm +1. I have a comment though: On 14/04/07, Glen Daniels <[EMAIL PROTECTED]> wrote: [...]
This way the only times we make fixes directly on the release branch are as follows: * For release-specific fixes (references to version number, taking out SNAPSHOTs, release notes, etc) * For post-release bug fixes - IF the trunk has moved on in an incompatible way (if the bug hasn't been fixed on trunk it should as per usual be fixed there first and merged)
If a user requires a fix in a branch surely they'll require it there whether it is compatible with the trunk or not. In fact I thought the release branches are typically closed once the release is out, then the trunk is used for the next release.
Otherwise, everything that goes into the release branch should be a merge over from the trunk. Sound reasonable?
Sounds good. I think this will give more flexibility in the timing of taking a branch from the trunk to do a release. History has shown the branch stays alive for longer than expected. Tracking which branches a fix goes to will hopefully prevent the need for a 'big merge' back to trunk - which is never pleasant. Thanks, Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
