Make dropping support for previously supported environments a breaking change

[markelog]

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?

[JacksonBailey]

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

[sikthehedgehog]

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)

[markelog]

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

[lamawithonel]

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.

[jwdonahue]

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