Question

I use Subversion and I stick to the trunk, tags, and branches convention.

The usage pattern I strive for is loosely the following:

1. start with trunk
2. do some work
3. tag release from trunk
4. deploy release
5. create a feature branch from a tag
6. do work
7. merge the branch with the trunk
8. go to step 3.

Given this pattern, one builds up quite a collection of tags over time. Do you retain those tags for very long, or is your policy to remove those tags that aren’t in production? My feeling is that it makes sense (especially in Subversion) to eventually “retire” old tags and depend on the history of the trunk and preserved tags if one needs the history, but what policies are in use?

Answer 1

My philosophy is that I usually lock tags – i.e. “freeze” the branch – once the code is released. Once source code in a branch isn’t in maintenance any longer, I remove the tags. So, usually this means that when the version for the tag is no longer “in the field”.

However, there are two assumptions here that I should make clear –

1. I usually branch/tag by release, not by feature. If I do create a branch for an experimental feature, I usually remove the branch after it’s been successfully merged into the trunk. Branch work is mostly just so I can isolate changes to the trunk while I’m working on something that will upset others.
2. My releases change very quickly, as I’m a mobile developer. So, it’s easy for me to say “when the release is no longer in the field”, because once I release new code, it tends to take over. It’s much more difficult for a developer whose code is going to be supported for years to come.

I guess it just comes down to ‘how long do you expect to support the code in this branch?’