feat: releases

[mbystedt]

The protection on the main will prevent this from working. Needs revision.

Some ideas:

• Ignore pom version completely
  • Always update the version in the pom before building
  • CI could take version as an optional param (non-versioned ones given version like: main-snapshot)
• Dev commits major (and minor?) version (no snapshot!)
  • Like above, but, check pom version and reject if tag doesn't start with pom version.
  • Example: pom.xml -> 1, tag: v1.2.4; Update pom.xml to 1.2.4 and build.
  • Example: pom.xml -> 1.0, tag: v1.2.4; Reject
  • Non tagged builds become the pom.xml version with -snapshot.

I'm warming to option 2. It's more complicated to implement, but, it has some good checks (can't accidentally release a whacky version). It could be coupled with a workflow (or locally run script) to increment the version after release.

[andrwils]

@mbystedt I might change my mind, but for now I like option 1, and that's the approach I'm using for experimentation. I commit a snapshot version at first and that lets my cycle through some deployments and testing, then I push a tag, say v1.0.0 and the workflow updates the pom file to use that tag as the version, commits the change and pushes the tag to GitHub. However, when I trigger the workflow by pushing a tag, the checkout is in a detached state, so when the tag gets pushed, it's not associated with a branch and I don't see the updated version in my branch's pom file.

[andrwils]

@mbystedt I've got the pom file update working and now I'm working on changing the deployment pipeline to deploy tags instead of branches. Once I have that worked out, I'll start looking at the tag validation in option 2.