On Aug 3, 2005, at 4:14 PM, David Blevins wrote:
On Wed, Aug 03, 2005 at 09:04:22AM -0400, Geir Magnusson Jr. wrote:
On Aug 2, 2005, at 9:41 PM, David Blevins wrote:
On Mon, Aug 01, 2005 at 07:16:23PM -0400, Geir Magnusson Jr. wrote:
no, you moved...
we never want to move branches, but copy to make tags, and never
modify the tags. That way, if we need to keep going on the branch,
we have it.
We agreed on this proceedure a month ago.
Clearly we agreed on a mistake then. I didn't read it carefully.
Sorry.
We want to be able to branch, work on the branch, and then tag for a
release (call it vX.0) Nothing in the tag is different from the
branch it came from - it's effectively a pointer to a moment in time
(revision) on the branch.
Now, suppose we have a security issue for which we want to do an
update on the thing we released. So we then must go back to the
*branch*, fix the bug, tag again (vX.0.1).
You've described my ideal setup for 1.0 and beyond, but we aren't
doing dot releases yet.
It shouldn't matter.
There is never going to be another release from the M4-QA branch.
It's a dead branch and shouldn't be updated after we vote to release
the M4 binaries.
Why wouldn't we set a process that's standard and stick with it?
Further, it's entirely reasonable to keep our option open for a
subsequent release of M4. Remember M3? And what if we find a major
problem? We don't want to ram forward a M5 - we'd want to fix M4 and
get that out there, retracting the problematic release, say a M4r1.
geir
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
