Widoco icon indicating copy to clipboard operation
Widoco copied to clipboard

Identify non-release builds as SNAPSHOT

Open paulmillar opened this issue 1 month ago • 2 comments

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.

paulmillar avatar Dec 04 '25 17:12 paulmillar

@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

dgarijo avatar Dec 05 '25 09:12 dgarijo

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 :smile:

paulmillar avatar Dec 05 '25 10:12 paulmillar