release_python_package.md: Impossible to change major version if the first major was 0

[Gu1nness]

The documentation of the release python package specifies that it should start with a minor v0.1.0.
However, the workflow will never bump a major version if the initial major version was 0 (see here).

It would be great to have a way to forcefully bump the major in that case, or remove the check last_version.major > 0 from the first test so that it's possible to bump the major in that case as well.

[syncronize-issues-to-jira]

Thank you for reporting your feedback to us!

The internal ticket has been created: https://warthogs.atlassian.net/browse/DPE-7768.

This message was autogenerated

[carlcsaposs-canonical]

Agree that this could be improved (or at least documented better) & was something I considered implementing before but had limited time

Some context about the current implementation, in case it's helpful:

For semantic versioning, breaking changes can bump the minor (or patch) version when major is 0 since there isn't a stable public interface

The default behavior when making a breaking change when major is 0 is to bump the minor version, since this seemed like the most common case

You can manually create a 1.0.0 tag and continue to use release_python_package.yaml and it will pick it up correctly & everything should work after the manual tag is created

[Gu1nness]

Ok, I'm fine with that but it would be great to document it in the md file.
Or add a specific flag to bump if the major is 0 ?