5

I've been looking into trunk based development recently (https://trunkbaseddevelopment.com) and what we do fits the approach nicely (small team, frequent releases, some direct commits or short-lived branches, etc.).

The only struggle I have is tagging the releases. We do CI but not every coming goes to production, and we want to increment (change) the version once the code is shipped to the customer's environment.

How in the trunk bases development (in an idiomatic way) should I do a release? How you feel with release commits on master? I can see two approaches (I'm using Java + Maven bit that's just tooling that should come in the way).

Approach #1

  1. //version information in trunk: 'SNAPSHOT'
  2. git checkout -b release/1.11
  3. // update version on release branch and commit
  4. // build the complete project and release
  5. git checkout master
  6. // continue with features

Approach #2

  1. // version information in trunk: '1.11-SNAPSHOT'
  2. git branch release/1.11
  3. // update version on the master branch to 1.12-SNAPSHOT'
  4. git checkout release/1.11
  5. // update version on release branch to '1.11' and commit
  6. // build the complete project and release
  7. git checkout master
  8. // continue with features

The second approach leaves a single commit in the repository's history, which I'm not sure how to feel about. The latter approach makes the code slightly more traceable and the release process a bit easier.

On a side note, I don't much care about bugfixes, etc. We do release a new version. But if a hotfix is required, we plan to cherry-pick

Jakub Marchwicki
  • 788
  • 9
  • 21

1 Answers1

6

Instead of creating release branches just to update the versions, treat every commit as releasable in true CI/CD fashion.

  1. // Version information in trunk: "SNAPSHOT", never edited by the developers, it is only used when built locally
  2. On every push to the trunk your CI tool builds and runs all tests and creates a releasable package. Before doing anything the CI tool substitutes the SNAPSHOT version to some unique version number (see below). This change of version is never commited, it is just used for building. For easy traceability the CI tool can add the unique version as a git tag pointing to the commit (This is not strictly required if the unique version number an be derived from git information as described below)

This way all you commits to the trunk are potential releases and no additional process except for noting down the unique version shipped to the customer needs to be done as part of a release.

Regarding unique version numbers I usually let the CI tool subsitute the SNAPSHOT version to something like <git commit date>-<short git commit hash>, which has the benefits of

  • Being truly unique (thanks to the hash)
  • Being easily interpreted and compared by a human (thanks to the date)
  • Being reproduceable (thanks to using git information)
danielorn
  • 5,254
  • 1
  • 18
  • 31
  • Thanks. I like the approach. I was thinking about similar fashion, to take the branch name and treat it's part as a human readable release version. But I like your `-` better. Will give it a try and once implementation works good I'll accept the answer – Jakub Marchwicki Jan 05 '19 at 15:01
  • I've stuck to `-`; I've also summarized this in the form of a blog post with Maven build script snippets (http://jakub.marchwicki.pl/posts/2019/01/05/release-in-trunk-based-devel/) to keep the question language independent. Thanks – Jakub Marchwicki Jan 05 '19 at 21:04
  • Why is the change of version never committed? Is it because, in trunk development, you push to the trunk so many times a day that you'd have many version commits a day? – BrainPermafrost Jan 07 '23 at 15:56
  • Also, I've have this idea of only running the version tool (whatever tool is used) when you branch off a release from the trunk. That can be committed as a tag on the trunk, would that work? So, only running the versioning tool, and committing a version tag, when a release is made, not on every push to trunk? – BrainPermafrost Jan 07 '23 at 16:01