Adopt semantic versioning
jlherren opened this issue · comments
Please consider adopting semantic versioning. Background is PR #340 that then caused issue #365. This kind of refactoring should not have been allowed in a minor release, it should have been a 1.4.0-ish change.
The advantage should be obvious: With semantic versioning one could put "apereo/phpcas": "~1.3.8" in composer.json and then be able to run composer update without fear of things breaking, because the 1.3.x development would receive nothing but bug fixes (no new features, no refactoring, nothing else). More adventurous users could use "^1.3.8" with a higher risk of breakage.
Thanks, for the feedback.
I guess this makes sense and would probably have been a good idea to make it clear for everyone to bump the minor version.
At the same time with only 2 partially active developers we will realistically probably never really maintain multiple minor versions for a longer duration.
At the same time with only 2 partially active developers we will realistically probably never really maintain multiple minor versions for a longer duration.
It wouldn't be required to maintain multiple minor versions. I know of projects that never release new patch versions once a new minor version is available, meaning that bugfixes only ever happen on the newest minor version. It's more about adequately communicating the risk associated with upgrading to a new version, so users know what to expect and can plan accordingly. A 1.3.9 release after 1.3.8 conveys a very different message than 1.4.0 after 1.3.8.
In addition this would probably require explicitly stating somewhere which version(s) are actively maintained, even if it's just one.
Fully agreed.
I just wanted to be upfront that having more clear version numbering will not address the underlying resource issues that cause our very simple linear development approach.
Release 1.4.0 has been released