Why moving Tag in Version Control System is a bad practice?

Question

Why moving Tag in Version Control System is a bad practice? I often run into this general suggestion, but have never seen explanations behind them.

Note: I'm using term "move tag" which I think is more relevant to CVS. But for SVN it's a similar concept when we just commit changes in tag folder.

My specific situation is here: I use SVN. I'm going to create tags automatically with build system. Right after creating new tag the build system is putting tag description information to one of tagged files, commits, and move tag on this changed file.

I can understand that if tag was set on project, and project was tested, then putting changes to tag may lead to misunderstanding between teams. Someone may checkout old version of a tag, and another person newer. But is anything bad in doing changes to tag before it was officially announced?

I suppose that decision to move tag or not may depend on type of project(commercial, opensource, individual), number of people working on the project, time passed after tag creation, development process type.

Answer 1

Tags are meant to represent project wide specific revisions of your source code and should not be used for other purposes. That said, strict adherence to this principle may lead to having to skip a release number, which may be just as unacceptable.

With complex build processes you should try and perform most of the work in release candidate branches and only tag at the very last moment. However it may happen that you need to fix something half-way and I consider it acceptable to perform small, controlled changes to the tagged version, especially if its existence hasn't been officially advertised yet.

Answer 2

Tags are normally considered as immutable snapshots of a particular state of the repository. Several tools, such as CI tools, work with this assumption. This is an important rule, it ensures that you have an unique way to reference a particular state of the project.

It's like a revision number in SVN or a SHA1 commit hash in Git. When people or tools reference a commit using a commit identifier, they are sure they are talking about a specific version.

The same applies to tags. If you work with the rule that once a state of the repository is tagged it can't change, it means everyone (including people and tools) can safely assume that if there is an issue, the issue exists for everybody. If the application behaves or misbehaves, then it will behave or misbehaves for anyone checking out that particular tag.

This is a very important concept to keep in mind because, once you break this assumption, you will likely to end up spending more time trying to debug with version of the tag you reference when reading a CI log or talking with other devs.