I think we, the community, needs to decide if we want to maintain
milestones going forward. This would include "we shouldn't but we
might want to..." (1) If we are maintaining milestones, I think we
should have the following structure:
branches/v1_0_M5
tags/v1_0_M5_0
This makes it clear to users that there may be an entry tags/v1_0_M5_1.
I personally don't think we should ever maintain something called a
"milestone". If we want to maintain the code we are calling
"milestone 5" I think we should rename this code to "release 0.5.0",
or we could just call it 1.0.0 :)
-dain
(1) This would not include exceptional, weird, or emergency cases.
If something exceptional happens, we come together as a community and
address the exceptional situation.
On Sep 19, 2005, at 11:55 AM, Geir Magnusson Jr. wrote:
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]
