Removal of features should be a "breaking change"

[robatwilliams]

I didn't find any version policy here. I propose that this project uses semver so that dependent packages avoid being broken by breaking changes made to the schema, and maintainers can learn about such breaking changes without reading every release note.

I use this package in my compatibility checker tool. When arithmetic operators were moved by #6246, it was released as a patch version although mentioned in the release notes. As is common practice, I used a version specifier ^1.0.25 to allow updates to any minor or patch version, expecting that any breaking change would be a major version. Since a breaking change was released as a patch version, it caused bug robatwilliams/es-compat#22.

Just to be clear, the breakage is my own fault because I assumed this project would use semver - due to it being common for npm packages.

[queengooborg]

Hey @robatwilliams, this is really big point, thanks for bringing it up. We do attempt to stick with semantic versioning rules, but we hadn't considered removal of features in the data to be a "breaking change". It seems, however, that this certainly qualifies as a breaking change; if we move/remove a feature's data that a package depends on, it may lead to code breakages like yours.

@ddbeck, you'll probably want to take a look at this one.

[ddbeck]

@robatwilliams Thank you for alerting me to this problem. Treating feature names as being subject to semver seems like a reasonable request to me. I was kinda thinking that this might be a good idea, but nobody complained before, so I hadn't acted on it yet.

I'm putting it on my to-do list to document our semver practices and flag that in a semver minor release. 😄

[ddbeck]

@robatwilliams An update on this: #7615 begins the process of protecting some parts of BCD for backwards compatibility and SemVer. If you have any thoughts on this, I'd appreciate your input on that PR (or issue #7563). It's not all encompassing (at least not yet), but it should limit the circumstances where a breakage like yours occurs.

[robatwilliams]

Both look good, I've put my comments on the issue.

As a tool maintainer I have a few options:

1. Lock down to exact dependency version, which stops users benefiting from data updates until I release.
2. Remain with my unsafe usage (or similar) which breaks the tool spectacularly so someone is likely to tell me about it.
3. Make the tool tolerant of missing data and report warnings to the user, which someone might tell me about
4. ... leading to the likely best solution - run the unit tests daily using the latest BCD that satisfies my dependency version string

[ddbeck]

OK, I think with v3.0.0 we've improved the situation quite a bit. Thank you again, @robatwilliams. I'm going to close this issue now, but please feel welcome to open new issues should we cause you any more trouble. 😅