Skip to content

Conversation

@paulmillar
Copy link
Contributor

Motivation:

Current builds contain a complete version, which could lead to confusion.

Modification:

Adopt maven's SNAPSHOT support. This is a feature where builds that are not from a release are given a SNAPSHOT label by appending -SNAPSHOT to the version string. The maven release plugin handles updating the version and tagging of releases.

Result:

Less confusion over intermediate builds.

Motivation:

Current builds contain a complete version, which could lead to
confusion.

Modification:

Adopt maven's SNAPSHOT support.  This is a feature where builds that are
not from a release are given a SNAPSHOT label by appending `-SNAPSHOT`
to the version string.  The maven `release` plugin handles updating the
version and tagging of releases.

Result:

Less confusion over intermediate builds.

Signed-off-by: Paul Millar <paul.millar@desy.de>
@dgarijo
Copy link
Owner

dgarijo commented Dec 5, 2025

@paulmillar sorry, do you mind elaborating a bit? I put the version in the pom.xml so when the releases are built they match the version in the release tag in GitHub.
If I add the snapshot, it would be inconsistent, no? I would like them to match the version of the releases in GitHub

@paulmillar
Copy link
Contributor Author

Hi @dgarijo,

This is a pattern we've used in other maven projects. Forgive me if I'm saying stuff you already know ....

The goal is that all non-release builds will have a version like x.y.z-SNAPSHOT. For example, the build process would produce jar files like widoco-1.4.26-SNAPSHOT-jar-with-dependencies.jar.

The idea is that SNAPSHOT is a clear signal that this isn't v1.4.26, but something that's "on the way" to becoming that version. It's also a signal that two jar files with the same name might not give the same behaviour (i.e., proceed with caution).

I believe there's also some additional behavioural changes; for example, when uploading build artefacts into a nexus repo (nexus supports stable and snapshot repos). Personally I haven't really used this feature.

The real magic comes with the maven release plugin. IIRC, the prepare target will:

  1. ensure the current repo is clean,
  2. build and test the repo,
  3. update the version (in the pom.xml and any maven modules), removing the -SNAPSHOT,
  4. commit that change,
  5. build and test the repo again,
  6. create a tag for the commit,
  7. update the version, bumping the version (e.g., 1.4.26 --> 1.4.27, 1.4.26 --> 1.5.0, ...) and adding the -SNAPSHOT suffix,
  8. commit that change.

The result is two commits and a new tag that you can pushed to GitHub as an atomic change.

The maven release plugin provides other targets, which provide more automation (e.g., updating a website). However, I've mostly used just the prepare target and manually pushed the result (although, perhaps not for good reasons).

The overall result is that git contains a single, tagged commit that has the version without the -SNAPSHOT suffix. All other commits have -SNAPSHOT in the version string.

This pull-request is only a suggestion. Please feel free to reject it, if this approach isn't appealing 😄

@dgarijo dgarijo self-requested a review December 23, 2025 12:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants