Hi,
As I'm already mentioned, I'm not in favor of the 2.x-SNAPSHOT approach,
and I don't see a significant problem with the Maven Release Plugin
pushing two commits during the release process. I think this is a
relatively minor addition to the commit history when compared to Dependabot.
Many ASF projects are using the Release Plugin without encountering this
issue, and Shiro releases have historically been made this way from the
beginning, without objection or problems.
I'm open to exploring new approaches, but I don't see the value in this
case. Using Jenkins to manage the release process shouldn't be
mandatory, especially for an external Jenkins instance.
Releasing involves signing the artifacts, a task that must be performed
by the releaser using their apache.org private key. So, I'm not
comfortable storing my private key on a Jenkins instance.
Finally, including the full version (2.0.7-SNAPSHOT) in the POM allows
for the publication of SNAPSHOT artifacts on the ASF Maven repository,
which helps users test.
regards,
François
Le 26/11/2025 à 03:47, [email protected] a écrit :
Hi,
I need to bring this topic up again.
I am proposing (again) to make release and deployment without changing the
source code in any way, as describer here:
https://www.cloudbees.com/blog/apache-maven-continuous-deliverydeployment-devoptics-teams-approach
I am also proposing to rename versions (once) in the source code from
2.0.7-SNAPSHOT to 2.x-SNAPSHOT (or even x-SNAPSHOT)
In the past, all 1.x releases were released the “old” way, which
maven-release-plugin checking 2 commits for every release:
- [release version] commit with all POM files updated to the exact release
version
- [next iteration] commit with all POM files rewritten again for the next
SNAPSHOT version
All 2.x releases (except 2.0.6) were done by me (using FlowLogix Jenkins
instance) using the “new” way:
- No commits were pushed associated with the release.
- Release was tagged from a branch made in Jenkins, which was then pushed to
GitHub without the code (which is perfectly supported)
François had some objections to the “new” process, and after a long discussion,
he volunteered to do the release (2.0.6) from his laptop the “old” way.
I believe that François’ main objection was that -SNAPSHOT releases were all
2.0.0-SNAPSHOT and not 2.0.4-SNAPSHOT, 2.0.6-SNAPSHOT, etc.
This is a valid objection.
However, after the release, I am realizing that going back to the “old” way has
raised some serious issues on it’s own:
- 2 commits per release seriously pollute the repository (major change 2x with
every release)
- In turn, this prevents clean merge of all changes from 2.x to 3.x branch
- Release plugin rewrites all pom.xml files which introduced issues in scripts
and unnecessary formatting changes, making pom.xml formatting worse.
I believe François’ objection can be easily resolved by using Jenkinsfile to
upgrade versions in the main build (with maven versions plugin) prior to build
/ deployment,
thus all SNAPSHOT releases will be properly versioned.
