tags:

views:

471

answers:

5

Hi.

I've seen a lot of projects using v1.2.3 as the naming convention for tags in git. I've also seen some use 1.2.3. Is there an officially endorsed style, or are there any good arguments for using either?

+1  A: 

Not that I know of.
But Git will not allow a tag and a branch of the same name at the same time, so if you have a branch "1.1" for 1.1 works, do not put a tag "1.1", use for instance "v1.1"

VonC
A: 

There is no one best practice I'm aware of. Here are some links:

Generally, versioning (0.0.1, v0.2.1, ...) maybe hand in hand with some issue-tracking could be considered a plausible approach. (.. although I usually use v-prefixed tag names .. see also @VonC answer)

The MYYN
+3  A: 

We use branches and tags for release-specific work followed by the actual release, respectively:

o---o-----o---o---o--- ...   master
     \   /       /
      \ /       /
       o-------o--- ...      1.6 branch

Every developer makes a mental decision about whether the work they're about to commit is applicable just to master or if it's also relevant to the branch. You can see that changes that are made to the branch are merged back on master, but some changes on master will never go on the branch (that is, those not intended for the 1.6 release, in this example).

When we're ready to release, we tag it and then merge back one last time, and we name the tag with the same name as the branch, but with an extra identifier about what particular version it is, e.g. "1.6-release" or "1.6-beta" or "1.6-rc2", et cetera.

... ------o---o---o--o---o--- ...   master
         /       /
        /       /
... ---o------(*)--- ...      1.6 branch
          1.6-release
John Feminella
Thanks - that's a good answer for describing how you do branching, but I actually just meant if there were some specific (technical) reason for using a certain naming scheme in git. Still giving you an upvote for the nice diagrams though ;)
troelskn
Ah, gotcha! Sorry for misunderstanding your question. No, there's no specific technical reason for using a particular name, other than human communication. You can name your branches and tags pretty much whatever you like.
John Feminella
A: 

I don't know of any standards. I simply choose my tag names such that I can stick a

VERSION = `git describe`

in my build scripts. So, the tag naming convention actually depends on the version naming convention of the project.

Jörg W Mittag
+6  A: 

There is Semantic Versioning, by Tom Preston-Werner of github fame:

Tagging Specification (SemVerTag)

This sub-specification SHOULD be used if you use a version control system (Git, Mercurial, SVN, etc) to store your code. Using this system allows automated tools to inspect your package and determine SemVer compliance and released versions.

  1. When tagging releases in a version control system, the tag for a version MUST be "vX.Y.Z" e.g. "v3.1.0".
peritus
Thanks - That's very close. I wish he would have qualified *why* the `v` should be there though.
troelskn
I see someone else had the same thought: http://github.com/mojombo/semver.org/issues/unreads#issue/1
troelskn
@troelskn @mojombo == Tom Preston-Werner
peritus