Why would a "branch" get moved to a "tag"? Why do we need branches
for revisions? Why are we deleting branches?
IMO, we should have a branch for each Major.Minor, where all of the
Major.Minor.Revision work happens. So branches/1.1 would hold the
active work for 1.1.x. When it is time to make a release, then svn
cp from branches/1.1 to tags/1.1.1, and then keep working on 1.1.2 on
branches/1.1
IMO, branches should never become tags. Tags only get copied to new
branches when we need to apply critical fix to a specific release,
otherwise we should just roll up the change into the next release of
the series.
I recommend minimizing branching where possible, so I don't think
that branches for 1.1.1 or 1.1.1.0 are a good idea. SVN is not that
good at merging, and making it simple (like Perforce), so lets try
not to set ourselves up for icky merges by making branches for each
release.
--jason
On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
After the branches/1.1 was moved to tags there was some question as
to what happened to the 1.1 branch. At that time some kind soul
created a new branches/1.1.1. No activity has occurred in that
branch and given that we'll need to define the release goals of
1.1.1 soon I'd like to propose the following.
After 1.1 is released:
* Delete branches/1.1.1
* Move branches/1.1.0 to tags/1.1.0
* Copy tags/1.1.0 to branches/1.1.1
* Update branches 1.1.1 to be 1.1.1-SNAPSHOT
* Start working on 1.1.1
When 1.1.1 enters time for release
* Move branches/1.1.1 to branches/1.1.1.0
* Change version from 1.1.1-SNAPSHOT to 1.1.1
* Create release candidate rc1
* put out for a vote
* get a successful vote with no respins :)
* move from branches/1.1.1.0 to tags/1.1.1.0
Based on all the confusion in the past I think this procedure makes
it clear what phase were in for the release as well as avoids
tagging and branching repeatedly.
I'm looking for lazy consensus and not a formal vote.
Matt
