SVN: Is valid to keep a TAG from a buggy released version?

Question

We created a TAG for a release version of one of our products (e.g. 4.3.0GA). Then we deployed it in production instances. next day the production instances totally crashed, making themselves absolutely unusable. we quickly release a new version fixing the bug. and put them in production.

Then we updated the our TAG (4.3.0GA) with the bug fixes. (yes, we made a direct commit to the TAG 4.3.0GA)

---

Then we came to this discussion inside our team:

Proposal A

We made a mistake. TAGs should never be updated. We have to revert the actual bug-fixed 4.3.0GA TAG to its initial state. and then create a new TAG named 4.3.0GASP1 with the bug fixes. Because every released version (even when it last only one day in production) should have a unique TAG in the repository.

Proposal B

Do not modify the actual repository's TAGs. Because if there is a 4.3.0GASP1 version, somebody could checkout by error the 4.3.0GA buggy version. TAGS should only contain non-buggy versions and finally, the buggy version only was in production for one day.

What do you think? Which posture is correct (Proposal A or B)?

UPDATE: We use the Jboss versioning convention by the way.

Answer 1

IMO, A and B have some truth in them.

As you may already know, tagging mechanism allows us to identify source-code related to a particular milestone. So, committing to a tag is a bad idea. Perhaps a hook/policy to prevent this is a good idea.

You could delete a tag if you think it leads to confusion/issues, since svn will record the change and allow you to revert back. However, a Wiki page or central spread-sheet with description of each tag/release# may also help (release notes?). Assuming that your team follows continuous integration, there may be a few builds tagged before you really identify the right one, so deleting unwanted tags may be an overhead.

Answer 2

Well, why not. Firstly, a tag is just a branch with a different nomenclature. There's technically no difference between the two. The difference is how you treat them.

So, should tags never be modified - that's a question you and your release procedures can answer. No-one can say you're wrong.

So - which one works best for you? That's the 'correct' answer.

I don't use tags at all, we leave released versions on the trunk and put a log comment on them, that way we never modify a released version, we have to release a new version of the latest code, but that fits our product suite (we'd get bogged down in hundreds of tags otherwise) and customers never want an older version - they always get the latest.

So you see how we 'violate' the best practices of version control, but as it works wonderfully for us, we don't care. We do what works for us.

EDIT: I think if you're going to have full-on traceability, you need a lot more than a tag branch that has one, and only one, version in it. The HEAD revision of each tag should still be sufficient for you in this case of a broken release that quickly gets fixed. It can also provide a trace of the fixes that were needed to make it of 'release quality'.

You could even make a tag of the product when it was released from dev and entered into test, and apply fixes to that until it was fully finished. So, instead of having a branch for testing and when test is complete you make a tag of that, you instead go straight to the tag branch, test using that and fix little bugs as they are found. When test is complete, the tag branch is made read only. In all cases, the HEAD revision is the only one that is used on that tag branch. This approach can sometimes cut down the complexity of releasing many versions into test, as once its finished dev, you have a stable product, even if it needs some tweaks.

Answer 3

In terms of best practices, you should have committed the bug fixes to the branch that you tagged 4.3.0GA from. Then created a new tag from the fixed branch. Of course that assumes also in terms of best practices that it was tagged from some sort of branches/release-4.3 maintenance branch instead of being tagged from a trunk that has been modified six ways from Sunday since the tag happened. You would also keep the buggy tag for posterity, because that is the point of the tagging concept.

In terms of your team Subversion makes no laws about it, a branch is just a branch, so you can do whatever you want. Although ofc you in that situation should probably be defined as the lead programmer, the release manager, or the whole team, i.e. whoever is responsible for making that decision. Having a olicy for RCS/VCS/SCM crap is probably smart for any non-trivial project.

---

It is good practice to have at least two branches for each release made.

One branch is for maintaining the code you released, the other is a never written to"tag" of what you actually released. Any release the user can download gets a tag, each major version released gets a maintenance branch. If a commit belongs in trunk and the release branches, well the SVN book and Google tell you what to do. I call it cherry pick and rebase but you can guess where I come from ;)

Answer 4

I tend to fall on the side of A:

IMHO, tags should be timeline markers that show the state of the codebase at a particular version or release. Even if that version was buggy, that was what shipped, and you should have a record of that in case you need to checkout and intentionally reproduce a bug which that release may have caused for clients, servers, or what-have-you.

Someone might get a buggy version of the codebase by checking out that tag, but aren't many tags also bug fixes? You shouldn't have to get into the dilemma of "Just how buggy is this release?" to determine what you do in your VCS. A release log stored outside of Subversion should help minimize bad checkouts.

My rule of thumb: If new code ships, it goes in a new tag.