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.
