Differentiate between minor and major releases

[matthewfeickert]

In PR #193 Scikit-HEP got a news page! 🎉 At the moment all the releases are noted as "major" even if they are "minor" releases in SemVer.

Example: boost-histogram v1.0.0 and pyhf v0.6.0 are both described as "major"

scikit-hep.github.io/pages/news.md

Lines 45 to 53 in e91e0c3

	**March 2021:** Major release `boost-histogram` 1.0.0 (Python 3 only),
	major release `histoprint` 2.0.0 (Python 3 only).
	Major metapackage release `scikit-hep` 3.0.0.
	**March 2021:** Package `root_pandas` marked as deprecated.
	**February 2021:** Major metapackage release `scikit-hep` 2.0.0.
	**February 2021:** Major release `pyhf` 0.6.0.

Should we adopt SemVer conventions and change the SemVer minor releases to be described as "minor"?

[eduardo-rodrigues]

Mea culpa. I can explain the rationale behind the wording:
I put "major releases e.g. in boost-histogram v1.0.0 and pyhf v0.6.0 because they effectively are. I mean, boost-histogram v1.0.0 clearly is and pyhf v0.6.0 effectively is because you're not on 1.x yet but the 0.x.0 are, I believe, the important "milestones." If you dislike we can simply remove the word "major" almost everywhere since the main piece of info if for sure the package name + "important" release. Would you prefer? I undestand your point. I hope you see my reasoning.

We do follow SemVer pretty much everywhere as far as I know.

[eduardo-rodrigues]

I'm happy to create a follow-up MR.

[matthewfeickert]

If you dislike we can simply remove the word "major" almost everywhere since the main piece of info if for sure the package name + "important" release.

This is probably fine. I don't see any problem differentiating between major, minor, patch releases as the libraries are already doing that in their release notes but I also don't see any problem with just going with what you implemented in PR #202.