You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue discusses the applicability of Semantic versioning (SemVer) for Modmail. I personally don’t believe we should use SemVer for our versioning scheme and my arguments are as followed. Feel free to continue this discussion below.
First of all, Modmail is not a public API, nor any API whatsoever, which is the fundamental principle of SemVer. Modmail is considered as an end-user software. This means that Modmail is under no obligation nor have any direct benefits from following SemVer.
“For this system to work, you first need to declare a public API.“ http://semver.org/
The reason behind why developers use semantic versioning is to prevent “dependency hell” for packages that depends on the API (referencing Modmail), but as Modmail is not an API and no packages actually relies on Modmail (they really shouldn’t), this does not apply.
What I believe we should be doing:
According to these respected QA forums, I came up with the following conclusions.
The general census for end-user applications is to make the version user friendly and deploy marketing strategies.
A simple versioning system can still remain as:
X.Y.Z
X = Major
Y = Minor
Z = Patch
However with the following pointers in mind:
Customers expect major releases to introduce significant changes, whether it be a great addition of feature or a rewritten interface, for these we should increment the major version.
Any relatively small introduction of features or changes that wouldn’t effect the overall experience of Modmail should increment the minor version.
Bug fixes and patches increment the patch version.
Small breaking changes shouldn’t be the worries even when released under a minor release, since updates are completely voluntary and reading the CHANGELOG is highly encouraged (however there should be a better way of relaying the CHANGELOG to the end user).
SemVer shouldn’t be the constraint for deploying a release under certain version increment, whether it be minor or major should be based more on customer expectations.
Miscellaneous:
All changes to Modmail should be made on a development branch and never to master directly, a pull request from development to master should always include a clearly written CHANGELOG and a version increment. A thorough review before PRing would prevent errors in the master (public) branch.
Please voice your opinions down below, anything constructive is welcome!
The text was updated successfully, but these errors were encountered:
This issue discusses the applicability of Semantic versioning (SemVer) for Modmail. I personally don’t believe we should use SemVer for our versioning scheme and my arguments are as followed. Feel free to continue this discussion below.
First of all, Modmail is not a public API, nor any API whatsoever, which is the fundamental principle of SemVer. Modmail is considered as an end-user software. This means that Modmail is under no obligation nor have any direct benefits from following SemVer.
The reason behind why developers use semantic versioning is to prevent “dependency hell” for packages that depends on the API (referencing Modmail), but as Modmail is not an API and no packages actually relies on Modmail (they really shouldn’t), this does not apply.
What I believe we should be doing:
According to these respected QA forums, I came up with the following conclusions.
The general census for end-user applications is to make the version user friendly and deploy marketing strategies.
A simple versioning system can still remain as:
However with the following pointers in mind:
Miscellaneous:
Please voice your opinions down below, anything constructive is welcome!
The text was updated successfully, but these errors were encountered: