1

I am leading a team of developers creating a Java library. We are following the standard Semantic Versioning model. The code is versioned with Git. Artifacts are built and pushed to an artifact server using Gradle.

As is the standard, the artifact version, when published, is determined in build.gradle with the line version 'xxx.xxx.xxx'. I want to enforce a policy that all merges to the master branch require that this version be changed. This is to ensure we don't accidentally publish a new artifact over an old version, which could cause a dependency nightmare for downstream users of our library.

It looks to me like the Git Client Side Hooks may hold the answer, but the methodology for scanning through the changes in a merge and looking for a particular one eludes me.

Note that I do not need the hook to do any intelligence around the changes to the version line. I trust the developers increment the values correctly. This is just about making sure a forgetful dev (which will undoubtedly be me) is reminded that the version needs to be changed.

J-bob
  • 259
  • 1
  • 5
  • Should each commit on master represent a release? What happens if there is a problem and you want to revert the master branch to an earlier version, how could you do that? Wouldn't it be better to put a quality gate before the actual release process to ensure that you are releasing a new version? An alternative is incrementing the release number directly *after* each release, but that doesn't play well with semver. – amon May 11 '20 at 16:10

0 Answers0