Development process with git workflow, branches and semver in mind

[beutlich]

@dietmarw When writing #3459 (comment), I noticed that we need to clarify the development process.

1. We should state that any changes requiring conversion got to MAJOR versions, here: MSL v5.0.0 wil be next. I noticed that you introduced the conversion label to mark/identify such issues
2. If we have a MINOR release scheduled as next release (say MSL v4.1.0 in fall 2020), we are not allowed to merge PRs with conversions to master, as long as both MINOR and MAJOR development happens on master. This means that we need to postpone this PR until release of MSL 4.1.0. As this might be seen unfortunate we might rethink the git workflow.

[dietmarw]

I think there is a misunderstanding probably also due to the Recommendation for a Release Process for Libraries using a different vocabulary than what SemVer would use.

Applying the SemVer vocabulary than a "maintenance" version is a new BUGFIX version. So in Autumn 2020 would be a new v4.0.1 due (we can still decided to release earlier since it is no rule but an recommendation).

Then a new main version does not automatically mean MAJOR but could just as well mean MINOR. Here it is basically up to MAP-LIB to decided if for example Spring 2021 it should already be a MSL v5.0.0 with conversion or a MSL v4.1.0.

And as I said the schedule is a recommendation and we can still decide to speed the process up or delay it. Due to our available resources it does not make sense to start development in parallel branches in parallel. We would simply not manage that (in my opinion).

[beutlich]

Agreed.

• New "maintenance" = BUGFIX releases for MSL 4.0.0 happen from maint/4.0.x branch.
• The master branch contains the new "main" version, either MAJORor MINOR, depending if backward compatibility breaking changes are added or not.