Adopt Semantic Versioning, adopt release branches

[EwoutH]

Currently the patch releases (like 1.2.1 and 1.2.2) are tagged from the default master branch, on which new feature development also happens, and thus include feature changes. This introduces instability on the patch releases, which isn't ideal for repositories wanting to use a stable version.

Therefore I would like to propose a few things to professionalize the development of HiGHS:

1. To adopt Semantic Versioning, meaning, in summary:

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards compatible manner, and
3. PATCH version when you make backwards compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

2. Keep release branches for each minor version. So maintenance and bug fixes occur on the release/1.2, release/1.3, and so on branches, while new features are merged into the master branch. Important changes can be backported if needed (cherrypicked).
3. No direct commits anymore to the master or release/* branches. An PR should be openend for each and give open-source contributors a chance to participate, and a place to get back to if it introduces unexpected behavior. Merge policies should be discussed (mainly who reviews/merges PRs)

This would improve stability of the HiGHS codebase hugely and improve documentation and code quality by using PRs.

@jajhall and @galabovaa I would like to know what you think! :)

[jajhall]

Thanks for your observations. As I understand, by creating branches corresponding to tagged releases we have well-defined and fixed codebase corresponding to each release. I don't understand why you think these might be compromised by future changes to master.

I'm also puzzled why you suggest the use of patch level numbering for bug fixes when that is what I feel we're doing.

There is a big difference between master and releases. The master branch is where we keep the most up-to-date version of HiGHS, allowing users access to features between releases. Other than trivial bug fixes, we don't permit direct commits to master. PRs to master are reviewed by at least one team member. I don't see any reason to "give open-source contributors a chance to participate". We engage with users in response to releases, and this has led to patch versions.

Whilst I accept that the release processes and documentation of HiGHS could be improved, we simply don't have the resources yet: we're not a commercial company! Perhaps the outstanding performance of HiGHS gives the impression that the team behind it is larger than it is.

[EwoutH]

Thanks for getting back so quickly, and being open for feedback!

As I understand, by creating branches corresponding to tagged releases we have well-defined and fixed codebase corresponding to each release. I don't understand why you think these might be compromised by future changes to master.

Indeed, for each tag an new branch is automatically generated and thus stable. The tag itself doesn't change.

What I meant is, creating a maintenance branch for each minor release, on which bugfixing for that minor release takes place. So before 1.3.0 is tagged, a release/1.3 (0or maintenance/1.3) branch is created. On that branch 1.3.0 is tagged, and then any future bugfixes for 1.3 are merged to that release/1.3 branch. Then from that branch, 1.3.1 is tagged, later 1.3.2, and so on. This way the maintenance branch only contains bugfixes that correspond to bugs on that minor version.

In this time new feature development can continue on the master branch, and when it's time, a new maintenance branch for 1.4 is created, and so on.

I'm also puzzled why you suggest the use of patch level numbering for bug fixes when that is what I feel we're doing.

For example, v1.2.2 contained two new features (read compressed files by using zstr and MPS file reader now parses further sections). Following Semantic Versioning that would be a minor release (so 1.3).

I don't see any reason to "give open-source contributors a chance to participate".

That's fine, there are many different styles of open source. Opening PRs allows to link to issues and help users to find out when and how behavior changed, but it's also a bit more effort.

we're not a commercial company! Perhaps the outstanding performance of HiGHS gives the impression that the team behind it is larger than it is.

Thank you for creating and maintaining this solver. I know it's hard work, it's appreciated.

[jajhall]

Thanks for the explanations. We will become steadily more professional in our project management, but we've been doing some of the things you suggest - like "Opening PRs allows to link to issues" - as a matter of routine. One reason we don't go to the effort of doing things like creating maintenance branches for versions is that there's almost no bug fixing to do.

[odow]

One reason we don't go to the effort of doing things like creating maintenance branches

I'd say the bigger reason is that you don't have the labor available to do so. You don't have the time to support 1.2.x as well as 1.3.y. Just keep ploughing ahead, if you add new features, bump the middle number and if you add new bug fixes, bump the end number. Don't be afraid of getting to something like v1.34.5. The only thing I would avoid is introducing breaking changes requiring a v2.x.y.

[jajhall]

We're doing this now