On 14/05/13 08:42, Jakob Frank wrote:
On 13 May 2013 22:13, Peter Ansell <[email protected]> wrote:
In the Git-Flow methodology there is a temporary "release-N.N.N" branch
created to bump the version numbers and do QA. This temporary branch is
then merged into both master and develop so that you never need to have a
backwards merge from master to develop.
Actually, while writing the proposal I was also thinking exactly about
such a temporary branch for release-preparation. But then I thought,
maybe it's too much branching involved and might get people
confused...
There is one point I'm not sure about: I'd like to have the final
release-tag on the "master"-branch, but with a "release-N.N.N"-branch
the vote (and so the tag) would be on this branch.
I know it's possible to update/change a tag in git, but Is is allowed
(from an ASF PoV) to modify the tag after the vote (which is
referenced in the vote-mail) in terms of release provenance? Mentors?
If changing the tag after the vote is no problem, then I'm +1 to
"release-N.N.N"-branches.
Best,
Jakob
I don't think anything directly precludes that but, aside from the git
specifics, the vote is on a certain state of the project and a certain
build. Making the vote on final release state is better IMHO.
Tags can be deleted - why not simply put one in the right place on
master if you want a marker before the vote (after merging back relevant
release cleaning). Delete if the vote fails.
(Are you really thinking of doing backports, and fixing old lines with a
new, separate ASF release on that line as a matter of course? Its a lot
more work than a single, rolling, latest current version - is there
sufficient benefit?)
Andy
