Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should we keep using semantic versioning? #319

Closed
Taaku18 opened this issue Jul 6, 2019 · 0 comments
Closed

Should we keep using semantic versioning? #319

Taaku18 opened this issue Jul 6, 2019 · 0 comments

Comments

@Taaku18
Copy link
Collaborator

Taaku18 commented Jul 6, 2019

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:https://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!

@Taaku18 Taaku18 pinned this issue Jul 6, 2019
@Taaku18 Taaku18 unpinned this issue Jul 27, 2019
@Taaku18 Taaku18 closed this as completed Aug 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant