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.

Sign up for GitHub

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

Jump to bottom

Add "package or API" in MAJOR version description #546

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Add "package or API" in MAJOR version description #546

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
2 changes: 1 addition & 1 deletion semver.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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,
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not agree that change is not needed. I strongly believe that SemVer needs this (or similar) clarification drastically.

People read SemVer spec

  1. 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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All those things are part of the software contract.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct. Do you suggest to change the wording to...?

  1. MAJOR version when you make incompatible software contract changes,

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"?

Copy link
Author

@koresar koresar Jun 11, 2020 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you believe a further (third) discussion is needed - let's move to the #444

1. MINOR version when you add functionality in a backwards compatible
manner, and
1. PATCH version when you make backwards compatible bug fixes.
Expand Down