Splits version bumping step into two separate steps

[nutjob4life]

🗒️ Summary

Merge this and you'll alter the way a roundup does an assembly. Previously, it had a "version bumping" step that would increase the version number in the system and commit it, then do the rest of the assembly.

However, as #124 noted, if a later step failed, that version number was already committed.

Merge this and "version bumping" gets split into two separate steps:

• An earlier step that increases the version number in the system, whether that's a Python VERSION.txt file or the <version> key in a Maven POM
• A later step that then commits the changed version file.

⚙️ Test Data and/or Report

You can see this work especially in Maven projects which are prone to Sonatype OSSRH central artifactory failures. Note, for example, the runs in the Maven sandbox repository (newer actions appear closer to the top, ignore the commit messages—look at the "branch" column):

• Before the fix
  • Roundup got triggered by tag release/5.4.0
  • It then triggered a commit to main, which would've been fine if release/5.4.0's Roundup hadn't failed in the OSSRH step—this is the step we want to avoid
• After the fix
  • Roundup got triggered by the tag release/5.5.0; it failed
  • However, above it, there's no commit to main
    • And I retried the release/5.5.0 two more times—both of which failed—and neither of which had a commit to main

Thankfully OSSRH is so flaky this was easy to test. For completion, I also tested it in the sandbox Python repository. There, you can see release/3.2.0 which was successful then triggered a commit of the VERSION.txt to main.

♻️ Related Issues

• 124

[nutjob4life]

👉 Note: to take effect, the stable tag for roundup-action will need to be moved to this merge.

[nutjob4life]

Moved stable