localgovdrupal
Strategy for major, minor, patch releases of localgov profile
@andybroomfield is keen to get clarity on this question.
This has come up in the discussing localgov_base 1.x and 2.x branches. https://github.com/localgovdrupal/localgov_base/issues/804
@andybroomfield raises the point that in the future we will want to remove support for localgov_base 1.x from
https://github.com/localgovdrupal/localgov/blob/3.x/composer.json#L29
Should this then be a major release?
See https://semver.org/
Perhaps yes!
MAJOR version when you make incompatible API changes MINOR version when you add functionality in a backward compatible manner PATCH version when you make backward compatible bug fixes
Yes, if it contains breaking changes that are not backwards compatible, it should be a major version to indicate this.
In my opinion, I would rename the current localgov 3.2.x profile branch to 4.x, currently this supports D10 and D11, my thinking is that we change this to be D11 only and change localgov_base from 1.x to 2.x so as part of the D11 upgrade we force the upgrade to 2.x at this stage rather than in future.
The way we specifically have 3.x for D10 and 4.x for D11, which should also make patching and modules easier now we are starting to see specific patches and modules for specific core versions.
I guess the decision/outcome of this we should log in an ADR somewhere for future reference.
