Thanks for your detailed explanation. I see you have an opinion about this, and I respect that. However, I still believe that there are some major issues with the “old” approach which, in my humble opinion, are more important than personal opinions, yours or mine.
Let me break down further your points, and hopefully I can convince you that the “new” way the better way, and worth doing. > 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. There is a huge difference between the dependabot commits and the release plugin commits. Dependabot commits change versions of dependencies (i.e. useful work), as the release plugin commits are basically just “paperwork” How does those commits help the history of the project? Would anyone do a useful diff between the two? Is any useful testing done? No. The [prepare for release] just gets overridden again by [prepare for next iteration] which makes it completely “dummy” commit. How do these two commits hurt the project on the other hand? They rewrite formatting and style of pom.xml, and they needlessly rewrite scripts with useless escapes. This is also “paperwork” which makes the project worse. But the biggest issue is the merge conflicts that are created by these commits. If a PR is active across releases, and you try to merge main into the PR, you get conflicts on many POM files. Same is true if main is merged into 3.x branch to pull in all outstanding improvements. You claim there is a solution, but I don’t think there is one, and if it is, it’s manual, labor-intensive and error-prone. (more “paperwork”) > Many ASF projects are using the Release Plugin without encountering this > issue, and Shiro releases have historically been made I see this as “we always done it this way, why change now?” - I think there is enough labor savings, simplification and quality-of-life improvements to justify the change. This is especially true since we have quite a few long-outstanding PRs and two branches that will be active for quite some time. Finally, I urge you to re-read the article https://www.cloudbees.com/blog/apache-maven-continuous-deliverydeployment-devoptics-teams-approach and truly understand why / what’s going on there. I didn’t “invent” this approach, and I am not the first one to use it or recommend it. — The rest of your points are good, and I agree with all of them. Let me elaborate: > Using Jenkins to manage the release process shouldn't be mandatory, > especially for an external Jenkins instance. Absolutely. I just personally (my opinion) don’t like the idea of releasing from the laptop. So I created a Jenkins job. We definitely want to migrate to Apache’s new tools when they are available. > not comfortable storing my private key on a Jenkins instance. Absolutely reasonable. > 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. Yes and no. No to having 2.0.7-SNAPSHOT in each POM file, but YES to publishing SNAPSHOTs with a version number. This can easily be adopted in the “new” way by modifying existing Apache Jenkins job that publishes SNAPSHOTs with the exact version to ASF Snapshot repository.. This is also described in the attached article. Bottom line, Francois that all of your valid arguments can be easily implemented with the “new” way, without having to pollute history with maven-release-plugin’s commits or having a minor/patch version stored in all POM files in the project. > On Nov 26, 2025, at 2:27 AM, Francois Papon <[email protected]> wrote: > > 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. >> >> >
