For the M1 release I would have said close enough and made the final
release from trunk.
But changing the tag is harmful by itself by setting precedence...
something which should not be followed, yet unless people understand
why, they will just continue along those bad practices.
And technically speaking, making a change to a branch or hacking up a
tag should have the exact same effect on any work that anyone might
need to redo for a release. And really we could thump the rule book
on the ci to tags too... which is pointless for this release. The
important thing is that people understand that its not appropriate to
alter a "tag" in that manner. This is a pure policy argument, as
technically from the release perspective is identical using svn, in
both cases, the release must be re-cut, re-approved, blah, blah,
blah. And in general for release tags, it is best to treat them as
read only.
--jason
On Dec 18, 2006, at 5:53 PM, David Blevins wrote:
On Dec 18, 2006, at 2:59 PM, Matt Hogstrom wrote:
Process of branching and tagging (we already have a plethora of
discussion...I think this needs to get on a Wiki)
- includes tags and modifications
Discussion, proposal, resolution and final vote.
http://cwiki.apache.org/GMOxPMGT/release-branching-process.html
Granted that was June, just about time to do it all over again :)
In regards to the commit to the tag, I don't have a problem with it
as it was completely ineffectual in any technical sense. We could
of course thump the rule book and make Matt redo 8+ hours of work
and have days worth of revoting followed up by a couple weeks worth
of cumulative man hours on policy discussions... or we could just
say "close enough" and focus on 2.0-M2.
-David
