Fix release process: derive version from POM, update all modules, bump next snapshot - #236
Merged
Merged
Conversation
…p next snapshot The release workflow had three issues that could cause incorrect releases or a broken reactor build: 1. The release version came from a manual workflow_dispatch input with no cross-check against the current POM version. A typo (e.g. entering 0.4.0 when the POM is at 0.5.0-SNAPSHOT) would release the wrong version. The input is now removed entirely; the workflow reads the POM version, verifies it is a -SNAPSHOT, and strips the suffix to derive the release version. 2. Only core and processor POMs were version-updated, but the reactor build (mvn verify with no -pl) includes example and example-custom-generator. The version mismatch could cause build failures or incorrect dependency resolution. All four modules are now updated together; only core and processor are still deployed to Maven Central. 3. After a release, main was left on the release version (e.g. 0.5.0) with no next-snapshot bump. A new "Prepare next snapshot version" step now computes the next minor snapshot (0.5.0 -> 0.6.0-SNAPSHOT), sets all POMs, and commits it as a second commit on the release branch. The git tag points to the first commit (release version), so it is unaffected. Both commits reach main via the same pull request. Additionally, the groupId of the example modules is unified to org.javahelpers.simple.builders (was io.github.java-helpers for example and org.javahelpers.simple.builders.example for example-custom-generator). Java package names are unchanged. RELEASE.md is updated to match the actual workflow behavior. Generated with [Devin](https://devin.ai) Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Contributor
Dependency ReviewThe following issues were found:
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The Maven Central release workflow had three issues that could cause incorrect releases or a broken reactor build:
Release version came from a manual input with no validation against the POM. The
workflow_dispatchaccepted a free-formrelease_versionstring. A typo (e.g. entering0.4.0when the POM is at0.5.0-SNAPSHOT) would silently release the wrong version — the only validation was semver format, not consistency with the current codebase state.exampleandexample-custom-generatorPOMs were not version-updated. The workflow only ranversions:seton the root,core, andprocessorPOMs, but the subsequentmvn -B clean verify -Prelease(no-pl) builds all four modules. The version mismatch between the example modules (still on0.5.0-SNAPSHOT) and core/processor (set to0.5.0) could cause build failures or incorrect dependency resolution.No next-snapshot bump after release. The PR opened by the workflow contained only the release version commit. When merged,
mainwould sit on a release version (e.g.0.5.0) instead of a-SNAPSHOT, which is wrong for continued development.Changes
.github/workflows/maven-central-release.ymlrelease_versioninput parameter. The workflow now reads the current POM version viamvn help:evaluate, verifies it's a-SNAPSHOT, strips the suffix, and uses that as the release version. This eliminates the risk of human error.core,processor,example,example-custom-generator) instead of only two. Onlycoreandprocessorare still deployed to Maven Central.0.5.0→0.6.0-SNAPSHOT), sets all POMs, and commits it as a second commit on the release branch. The git tag points to the first commit (release version), so it is unaffected. Both commits reachmainvia the same pull request.--force-with-leaseto handle the second commit cleanly.example/pom.xmlio.github.java-helpers→org.javahelpers.simple.buildersexample-custom-generatorupdated to new groupIdexample-custom-generator/pom.xmlorg.javahelpers.simple.builders.example→org.javahelpers.simple.buildersexample-custom-generator/README.mdRELEASE.mdVerification
mvn clean install) passes — all 5 modules, all tests green (26 example tests + full processor test suite)mvn help:evaluate -Dexpression=project.version -q -DforceStdoutcorrectly returns0.5.0-SNAPSHOT(confirms the version-reading approach the workflow uses)0.5.0→0.6.0-SNAPSHOT,0.6.0→0.7.0-SNAPSHOTNotes
exampleandexample-custom-generatormodules are version-updated alongside the released modules but are not deployed to Maven Central (deploy step still uses-pl core,processor).mainbranch must always be on a-SNAPSHOTversion after this change. The workflow will fail with a clear error message if it isn't.org.javahelpers.simple.builders.example) are unchanged — only Maven groupIds were unified.