This is a subject with too much heat and smoke and weird accusations
of commercial motivations to boot, so lets just have this out and
keep moving.
I have heard from two people that my position appears either entirely
or partially influenced by IBMs interest in offering support for a
milestone release, and thus I want to keep branches around so an
update to a milestone can be done if someone wants it. My only
response, other than "baloney", is that because SVN keeps everything,
we can always bring the branch back to do an update to a milestone,
so wrt what IBM wants to do, it's moot. The PMC dictates if a
release happens, not the structure of SVN.
So...
I'd like to see a regular, formal policy for how we do branches and
tags. it makes it easier for newcomers to understand, and for us to
create a process that outlives us. We might as well rope in
Jeremy's thoughts on a stable branch and an unstable branch a la
Linux and Httpd as well.
To me, a tag is a pointer to some branch. It's a little different in
SVN since SVN doesn't actually have branches and tags, but they are
just fabricated because we're used to CVS.
Will we ever let someone do an update to a release that was called
"milestone"? I see no problem in letting that happen if someone
wants to do it, although I think it's highly unlikely. I think that
this issue is tangential to the discussion, because an update to a
milestone is determined by PMC vote, not visible existence of a
branch in SVN.
Some people think we need no history for milestones, but the fact is
that we are trying to get people to use our milestones (not just
IBM), and I think that it behooves us to provide as good user support
as possible, to the extent that some users want it. Maybe we adopt
an N-1 policy for milestones? So if we release M5, we keep M4
around, and delete M3, M2, M1. if we release m6, we delete M4, etc.
Now, Dain correctly points out that having both branches and tags is
a waste of space. So since mechanically branch and tag are the same
thing (copies) can we just stop creating new branches altogether for
releases, and have a trunk that we tag from? Two approaches off hand :
a) we work on our release candidate in trunk until we are
satisfied, and then do a tag, do the final testing, and release
that. If it fails, we fix in trunk, and then tag, test and release.
That means that dev has to slow down (or cease!) in trunk between tag
time and release time.
b) We have a trunk/1.0 and trunk/1.1 where 1.0 is our released
version and can fix and tag 1.0.x all we want without worrying about
stopping work in trunk/1.1, while releasing new and zany stuff as our
1.1.x release stream. Then when we are happy w/ 1.1, we make that
1.2 and 1.3 at the same time, and focus on 1.2.x as stable, and 1.3.x
as dev updates. I don't know how to start this off, actually,
because we either could abandon the Mx thingy and do a 0.9 as we
drive to 1.0, or just keep the Mx thingy and start w/ 1.0, 1.1
When I was active with velocity, I would tag for a release, and just
keep moving. In the event we had to go backwards and do an update,
we'd turn the tag into a branch, fix the branch, and then do a new
tag and release. This worked well, but over time, it became
confusing, as some releases had branches, and some didn't. That's
why I'm interested in something regular and formal.
Comments? We've been around this issue a few times, and should just
put it to rest in a way that makes us all satisfied.
geir
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
