How semantic versioning fits into the git workflow

Question

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?

Answer 1

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.