Introduce new SemVer policies

[slawekjaranowski]

• add more SemVer implementations
• improve documentation
• improve tests for version policies

---

Following this checklist to help us incorporate your
contribution quickly and easily:

• Your pull request should address just one issue, without pulling in other changes.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body.
  Note that commits might be squashed by a maintainer on merge.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied.
  This may not always be possible but is a best-practice.
• Run mvn verify to make sure basic checks pass.
  A more thorough check will be performed on your pull request automatically.
• You have run the integration tests successfully (mvn -Prun-its verify).

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004
• In any other case, please file an Apache Individual Contributor License Agreement.

[kwin]

For me the overall goal is a bit unclear. Usually release policies only make sense if they are always the same (not only used for a single release), otherwise one could just as well override the default versions with explicit parameters. With SemVer however the version numbering always depends on the underlying changes. There is no way to automatically tell which part of the version you need to increment. Toggling the release policy for each release does not make much sense to me. Why not stick with the default and rely on the release manager to set the right version then?

[slawekjaranowski]

Agree that release manager depends on change log for release take a decision about next version.

In system when release is made by CI we have currently two options

• change version in code before release - sometime require full change flow with approvals and so
• allow to enter specific version manually as CI pipeline argument - can be error prone

With more flexible versions policy we can provide an option in CI which allow to select which version should be changed

• release manager can select which version should be bump for next release major, minor or patch

[kwin]

If this is just about being able to release in non-interactive mode, why not just setting parameter releaseVersion and developmentVersion in the pom.xml. Changing the https://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#projectVersionPolicyId with every release doesn't sound reasonable to me. IMHO this is rather to enforce a common schema across all releases.

[slawekjaranowski]

I don't want to change project source code before each release.

projectVersionPolicyId will be set as default value in code, it can be set by CI on cli.

My idea is to have an option in CI pipeline, when release manage start a new release, can select one simple option on CI level without entering manual values for next version.

Settings releaseVersion or developmentVersion in source code have no value ... it must be changed before each release.

Like for GitHub workflow we can provide an input parameter - https://github.com/proxy/docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#onworkflow_dispatchinputs - there is a choice type, so I can simply provide predefined values for version policy.

[kwin]

Now I see, so projectVersionPolicyId SemVer* is not supposed to be set within the pom.xml but always via CLI argument becaue it always differs. Probably would be worth to document at https://github.com/apache/maven-release/pull/1424/files#diff-527a16ff0fbf21825bf7287faf9d89d9261c303f702c1af08b7613df1f4102f4R35 because this is fundamentally different from other policies (in general for me the term policy is more associated with a rule which should always be applied).

[slawekjaranowski]

Now I see, so projectVersionPolicyId SemVer* is not supposed to be set within the pom.xml but always via CLI argument becaue it always differs. Probably would be worth to document at https://github.com/apache/maven-release/pull/1424/files#diff-527a16ff0fbf21825bf7287faf9d89d9261c303f702c1af08b7613df1f4102f4R35 because this is fundamentally different from other policies (in general for me the term policy is more associated with a rule which should always be applied).

It depends if someone alway want to bump eg minor version (never mind of reason) for all releases can set it in project pom.xml

But yes I think about using by CI on cli level

What is your proposition for documentation improvement?

[slawekjaranowski]

@kwin do you have more objections, I would like to merge it and finally release next version

[pzygielo]

• https://github.com/apache/maven-release/pull/1430/files#r2568291575