[GH-ISSUE #317] Make dropping support for previously supported environments a breaking change #4472

New Issue

GiteaMirror · 2026-06-13T12:33:53-05:00

GiteaMirror commented

2026-06-13 12:33:53 -05:00

Originally created by @markelog on GitHub (Jun 22, 2016).
Original GitHub issue: https://github.com/semver/semver/issues/317

It seems if project dropping support for previously supported environment it should be a breaking change.

Since this wording -

MAJOR version when you make incompatible API changes

Implies that API needs to be changed, not internal "workarounds" for such environment, can we make it more clear?

Originally created by @markelog on GitHub (Jun 22, 2016). Original GitHub issue: https://github.com/semver/semver/issues/317 It seems if project dropping support for previously supported environment it should be a breaking change. Since this wording - > MAJOR version when you make incompatible API changes Implies that API needs to be changed, not internal "workarounds" for such environment, can we make it more clear?

GiteaMirror closed this issue

2026-06-13 12:33:53 -05:00

GiteaMirror commented

2026-06-13 12:33:54 -05:00

@JacksonBailey commented on GitHub (Jul 11, 2016):

@markelog can you explain a little more what you mean by "previously supported environment"?

@JacksonBailey commented on GitHub (Jul 11, 2016): @markelog can you explain a little more what you mean by "previously supported environment"?

GiteaMirror commented

2026-06-13 12:33:55 -05:00

@sikthehedgehog commented on GitHub (Jul 15, 2016):

I suppose that would include situations like dropping support for an old operating system? (which effectively makes the software stop working even if the API functionality would otherwise remain compatible)

@sikthehedgehog commented on GitHub (Jul 15, 2016): I suppose that would include situations like dropping support for an old operating system? (which effectively makes the software stop working even if the API functionality would otherwise remain compatible)

GiteaMirror commented

2026-06-13 12:33:55 -05:00

@markelog commented on GitHub (Jul 15, 2016):

I suppose that would include situations like dropping support for an old operating system? (which effectively makes the software stop working even if the API functionality would otherwise remain compatible)

Yes, that's exactly what i mean. Example from the environment close to my dev stack would be dropping support for older node.js versions - newer ones allow ES6 syntax which is not supported by the older versions so using newer language constructions without changing the API will break project on such environments.

I suppose this rule already exist de facto and adhere to the spirit of this spec, but it would be nice if it would be explicitly mentioned so there wouldn't be any doubt about that

@markelog commented on GitHub (Jul 15, 2016): > I suppose that would include situations like dropping support for an old operating system? (which effectively makes the software stop working even if the API functionality would otherwise remain compatible) Yes, that's exactly what i mean. Example from the environment close to my dev stack would be dropping support for older node.js versions - newer ones allow ES6 syntax which is not supported by the older versions so using newer language constructions without changing the API will break project on such environments. I suppose this rule already exist de facto and adhere to the spirit of this spec, but it would be nice if it would be explicitly mentioned so there wouldn't be any doubt about that

GiteaMirror commented

2026-06-13 12:33:55 -05:00

@lamawithonel commented on GitHub (Apr 18, 2018):

I agree that this should be an explicit part of the specification. The way I see it, breakage isn't restricted to the API, but happens in the contract with the user or consumer, be that a developer, an end-user, or a piece of software. Essentially, given a runtime environment AND a set of inputs (the classic API), the software should return the same set of outputs and behaviors. If the return set grows, that is a feature addition (MINOR change); if the set shrinks or ceases to work altogether, e.g., throwing an error instead of completing, that is a breakage (MAJOR change).

Here's a common example:

I write a library that works with Ruby 1.9.x, 2.0.x, and 2.1.x.
I specify that it works with only these versions in my gemspec file
If I make non-API changes which enables it to further run with Ruby version 2.2.x through 2.6.x, I see that as a MINOR change (feature addition)
If I make non-API changes that prevent it from running on Ruby 1.9.x, I see that as a MAJOR (breaking) change

And an OS example:

I write a simple program which may technically compile and run on Win32, Win64, and Linux, both i386 and amd64 (ignoring libc and compilers for clarity)
In my documentation I declare that it supports only Win64 and Linux amd64
If I change my documentation to indicate that it also supports Win32 and Linux i386, I see that as a PATCH change
If I make non-API changes to to enable compilation on OpenBSD amd64, I see that as a MINOR change
If I make non-API changes which prevents it from compiling on Win32 after indicating support for it in my documentation, I see that as a MAJOR change
If I make those same non-API changes to break compilation on Win32 before indicating support for Win32 in my documentation, I see that as a PATCH change, because it was not officially supported.

This all rests on a declaring a supported environment. This similar if not equivalent to the concept of a public API outlined in SemVer 2.0.0. Based on that, I'd say this is currently covered in the spirit of the specification. The problem I see is disagreement over the letter of the specification. Whether the official SemVer decides to encompass the environment or not, I would like to see it written out explicitly.

Addressing issue #331 might help here.

@lamawithonel commented on GitHub (Apr 18, 2018): I agree that this should be an explicit part of the specification. The way I see it, *breakage* isn't restricted to the API, but happens in the contract with the *user* or *consumer*, be that a developer, an end-user, or a piece of software. Essentially, given a runtime environment AND a set of inputs (the classic API), the software should return the same set of outputs and behaviors. If the return set grows, that is a feature addition (MINOR change); if the set shrinks or ceases to work altogether, e.g., throwing an error instead of completing, that is a breakage (MAJOR change). Here's a common example: * I write a library that works with Ruby 1.9.x, 2.0.x, and 2.1.x. * I specify that it works with only these versions in my gemspec file * If I make non-API changes which enables it to further run with Ruby version 2.2.x through 2.6.x, I see that as a MINOR change (feature addition) * If I make non-API changes that prevent it from running on Ruby 1.9.x, I see that as a MAJOR (breaking) change And an OS example: * I write a simple program which may technically compile and run on Win32, Win64, and Linux, both i386 and amd64 (ignoring libc and compilers for clarity) * In my documentation I declare that it supports only Win64 and Linux amd64 * If I change my documentation to indicate that it also supports Win32 and Linux i386, I see that as a PATCH change * If I make non-API changes to to enable compilation on OpenBSD amd64, I see that as a MINOR change * If I make non-API changes which prevents it from compiling on Win32 *after* indicating support for it in my documentation, I see that as a MAJOR change * If I make those same non-API changes to break compilation on Win32 *before* indicating support for Win32 in my documentation, I see that as a PATCH change, because it was not officially supported. This all rests on a declaring a **_supported environment_**. This similar if not equivalent to the concept of a **_public API_** outlined in SemVer 2.0.0. Based on that, I'd say this is currently covered in the spirit of the specification. The problem I see is disagreement over the letter of the specification. Whether the official SemVer decides to encompass the environment or not, I would like to see it written out explicitly. Addressing issue #331 might help here.

GiteaMirror commented

2026-06-13 12:33:56 -05:00

@jwdonahue commented on GitHub (Oct 9, 2018):

@markelog

I've tried to consolidate all of the "API should be changed X" and similar issues into #468. Please contribute to this discussion on that thread and close this one at your earliest possible convenience.

Thank you.

@jwdonahue commented on GitHub (Oct 9, 2018): @markelog I've tried to consolidate all of the "API should be changed X" and similar issues into #468. Please contribute to this discussion on that thread and close this one at your earliest possible convenience. Thank you.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#4472