How semantic versioning fits into the git workflow

Go To StackoverFlow.com

7

I'm currently having trouble using semantic versioning with git.

We are using the git versioning model at http://nvie.com/posts/a-successful-git-branching-model/

We would also like to follow the semantic versioning guidelines outlined at http://semver.org/

Here is a sample use case for us.

Release branch: ----1----2----3----4 <- tag v1.2        ----7---8---9 <- tag v1.3
                   /                \                  /             \
Develop branch: --0--------5---------4--6-----------------------------9--

Here's our sample use case:

  • Development occurs in parallel on release and develop
  • Release is ready to go, we tag it as v1.2. We generate release notes for changes 1, 2, 3, 4.
  • We merge release back to develop.
  • When we are ready to branch of develop again for another release, we can. However, tag v1.2 is pointing to 4, so the release notes for 5 is effectively lost if we query for changes between v1.2 and v1.3

What we would like to do is to be able to search for all newly added checkins since tag v1.2 was created that are newly incorporated into tag v1.3 so that we can determine what kind of version bump (x.y.z) for our component we need to make.

If 5 happened to be a major change, but everything from v1.2 onwards isn't, we will incorrectly bump the minor version since checkin 5 was not in the build.

Does anyone have any suggestions on how this can be solved?

2012-04-03 23:13
by Adrian Chung


2

I guess that depends on how you “query for changes”. But if you mean using git log v1.2..v1.3, or something like that, then that should show you exactly what you want, that is, including commit 5.

2012-04-04 01:09
by svick
If we use git log v1.2..v1.3, then commit 5 would be excluded because HEAD for develop would be pointing to commit 4 after merging from release v1.2 back down to develop right? Hence commit 5 would be inserted before commit 4, so commit 5 would essentially be considered "covered" already since HEAD is pointing to commit 4 - Adrian Chung 2012-04-04 03:20
No, it really wouldn't be excluded. Have you tried it? v1.2..v1.3 for git means “commits that are in v1.3, excluding those in v1.2”, which means it will include 5 - svick 2012-04-04 09:05
I tried it in a sample repo and you're right. Thanks! My confusion was that I was thinking of HEAD to release v1.3 tag instead of v1.2 to v1.3 - Adrian Chung 2012-04-04 13:23