Add "package or API" in MAJOR version description #546
Conversation
|
Should this change be released as SemVer 2.0.1 though? |
|
Versioning of the spec itself has been a sore point for many of us. There have been many patch level updates to the spec and FAQ that have not resulted in any version bumps. It's kind of sad actually. Bugs have been filed for this in the past. |
|
How about the change? Does it require other people opinions? |
|
@koresar, see the CONTRIBUTING.md document. I am not a "maintainer" in any official sense, so I can't commit anything. I just like to keep my head in this space, so that the next time I have a block of time to work on something, I can roll my VersionMeta and VersionSchema rocks along. |
|
should such change to the specification itself be a major version, i.e semver 3.0.0? :) |
|
No, I think it's minor change. |
| @@ -6,7 +6,7 @@ Summary | |||
|
|
|||
| Given a version number MAJOR.MINOR.PATCH, increment the: | |||
|
|
|||
| 1. MAJOR version when you make incompatible API changes, | |||
| 1. MAJOR version when you make incompatible package or API changes, | |||
There was a problem hiding this comment.
It's unclear in the context of this document what a "package change" is. What an API is isn't explained either but we should rather better define "API" than add more ambiguous terms.
Especially in the context of #444, I don't think we need to make any change. The API could include the necessary environment. In the end you have to document how to use it. This could mean "node@^10" which would make any change to the supported node version a SemVer MAJOR. Or it could mean "node versions currently marked as LTS" which means some node versions will be unsupported at some point.
There was a problem hiding this comment.
I would not agree that change is not needed. I strongly believe that SemVer needs this (or similar) clarification drastically.
People read SemVer spec
- MAJOR version when you make incompatible API changes,
as
I can change ANYTHING except the software contract (aka API) to avoid MAJOR version bump.
In my practice, inexperienced people where changing such things as: OS support, browser engine support, removed functionality, and most notably - runtime versions support. All that without major version bump.
It caused millions of $$ revenue loss for some companies.
You are saying - "could mean", but I'm saying - what it actually meant already.
Let's not put theories, instead let's look at past practice, at the events which actually happened.
I would agree that wording of this PR could be better. I welcome you to find better words.
There was a problem hiding this comment.
All those things are part of the software contract.
There was a problem hiding this comment.
Correct. Do you suggest to change the wording to...?
- MAJOR version when you make incompatible software contract changes,
There was a problem hiding this comment.
I'm saying that that's what API means, and thus "API" is sufficient.
If people are going to misunderstand "API", then what's stopping them from misunderstanding "software contract"?
There was a problem hiding this comment.
"API" is a subset of "software contract". IMO.
"software contract" can also include such things as encoding, protocol(s), platform(s), package type, language(s), etc.
If you believe people would misunderstand "software contract" then please come up with better wording. Or, perhaps, a better PR.
There was a problem hiding this comment.
If you believe a further (third) discussion is needed - let's move to the #444
|
Closing & re-opening to trigger CI |
alexandrtovmach
added
extend
As discussed in #444 with @jwdonahue, I'm supplying a PR which clearly states that even if API does not change but a software update breaks something then it should be a MAJOR release.
Closes #444
Previous attempt: #452