Describe Volta's SemVer commitments (COMPATIBILITY.md) #1619
Conversation
chriskrycho
force-pushed
the
describe-semver
branch
2 times, most recently
from
693b4d0
to
fb7fb94
Compare
Co-authored-by: Rob Jackson <[email protected]>
chriskrycho
force-pushed
the
describe-semver
branch
from
fb7fb94
to
d471187
Compare
| - Linux x86-64 | ||
| - Windows x86-64 | ||
|
|
||
| We compile release artifacts compatible with the following, and likewise will treat it as a breaking change to drop support for them: |
There was a problem hiding this comment.
While not written down, this has effectively been our policy up until now. It's definitely caused some complications, especially around maintaining the CI / release GitHub actions.
I'm generally in favor of changing the supported versions being a breaking change. I think we should be aware of how often we find ourselves needing to bump the major, to avoid churn, but up till now that hasn't been an issue.
I also wonder if it's worth explicitly adopting a model similar to Ember's, where our major changes are mostly added in backwards-compatible minor versions, and the Major bumps are explicitly only for removing deprecated features, dropping support for old OSes, etc.
There was a problem hiding this comment.
Both of those instincts—keep an eye on making sure breaking releases are rare, and only use them for actually breaking changes—match my own. That being said, we should think hard about our “messaging” strategy around that; “Volta 2.0 has no new features in it!” definitely will confuse people, from our experience with Ember. I still like it and think it is good, but because versioning does double duty when using SemVer (communication about changes and marketing), and because the marketing version number is an inescapable reality because that’s how the entire rest of the ecosystem uses it (and has for decades!), we will want a message about our thinking there.
| - macOS v11 | ||
| - RHEL and CentOS v6 |
There was a problem hiding this comment.
One thing #1611 made me think about: since w/v2.0 we will bump our minimum supported version of RHEL/CentOS to v6, is there any reason to bump the minimum supported macOS version? Apple has not been patching macOS 11 for a while now; macOS 12 is the earliest version they are still doing security releases for. (Technically, they only guarantee support for the current version, but in practice still provide some degree of security patching back a couple versions; it seems like the usual effective policy at this point is "most recent three major releases".)
The flip side is we are not necessarily gaining anything by moving.
There was a problem hiding this comment.
Yeah, I think bumping the macOS one is good as well! In fact, I'm not sure what our actual minimum supported macOS version is, since we build in CI on macos-latest. But in any event, AFAIK we haven't gotten any reports of issues where we aren't supporting an old version on macOS.
There was a problem hiding this comment.
My mild inclination would be to target 12 for the upcoming change, then. I will leave this as is, so it correctly documents what we do now, and then we can update it when we do the 2.0 release, and I will also update our build configuration accordingly. 🎉
While discussing #1611, @rwjblue and I noticed that we do not have any explicit documentation of our SemVer/compatibility policy. We should specify what versions of our main targeted operating systems we support.
Additionally, this proposes that dropping support for a currently-supported version will be a major version bump for Volta—so, e.g. when #1611 itself lands, we should release 2.0 afterwards, since it will drop support for the EOL'd RHEL 6 line. As an alternative, we could consider treating operating system support similar to the way most crates treat Rust support and the way most JS packages treat Node versions: non-breaking to drop support for EOL versions.