3

I have been reading a bit more about trunk based development, my company currently mainly uses the git flow model, and I had a question regarding the commits that happen on the trunk and how they are versioned.

I'll use the Paul Hammant blog post to try and keep the question less subjective. So below we have the branching model from his blog post

enter image description here

I'm interested in what 'version' each of the green commits generates from the trunk. Exampleafter the cherry pick to generate 1.1.1 there are about 15 commits on trunk before we branch the 1.2.X version. Each time those commits go on to the trunk I am assuming the trunk is built and unit tested (maybe even goes to a staging environment) so what version are those commits? Does it matter?

TC picks up one of the commits and builds the projects and unit tests. Does it generate an artifact? I'm wondering about how you would then deploy it via Chef or similar to the staging environment if that is indeed what you do with trunk based dev like this.

I'm guessing in environments were there are dozens of changes every day the versioning must either be automated (a semantic delta added by way of the commit message) or not seen as very important due to the high volume and flux of changes.

Improve this question

2 Answers 2

Reset to default
2

What version number to use for builds made from trunk is entirely up to you (or rather, your organization).

Some possible options are:

  • No version number at all
  • Version 0.0
  • The version of the last official release
  • The version of the next official release

To differentiate "trunk-builds" from official releases, it is common to add a suffix like snapshot-<DATETIME> to the version number. Adding the date and time of the build also helps to keep the various "trunk-builds" apart from each other.

Improve this answer
3

Reading that blog post it would seem that the versioning is only done on the release branch.

If you think about it, after the inital branch the cherry picked bug fix commits are essentialy new code changes to the branch. ie the code for release branch commit 1.x wont exist anywhere on the trunk. So if you did version trunk commits they would be out of sync with the release version numbers.

I'm not sure how proponents of this model can argue that a cherry picked bug fix merged from trunk is any different from a bug fix commit on the release which is merged to the trunk.

Obviously the trunk commit without the benefit of the commits before it wont be guarenteed to work on the release and will require additonal work and testing

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.