Describe Volta's SemVer commitments (COMPATIBILITY.md) #1619
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,17 @@ | ||
| # Compatibility | ||
|
|
||
| Volta currently tests against the following platforms, and will treat it as a breaking change to drop support for them: | ||
|
|
||
| - macOS | ||
| - x86-64 | ||
| - Apple Silicon | ||
| - 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: | ||
|
|
||
| - macOS v11 | ||
| - RHEL and CentOS v6 | ||
|
Comment on lines
+13
to
+14
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 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. 🎉 |
||
| - Windows 10 | ||
|
|
||
| In general, Volta should build and run against any other modern hardware and operating system supported by stable Rust, and we will make a best effort not to break them. However, we do *not* include them in our SemVer guarantees or test against them. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.