Any reason why babel doesn't strictly follow semver?

[MatthewHerbst]

I've noticed that lots of patch release versions of babel include New Feature sections in their release notes. It's my understanding that patch releases should not be introducing new features if semver is strictly being followed.

What criteria does the project use to decide on when to make a minor version change?

[nicolo-ribaudo]

Sometimes it's really hard to decide what should go in a patch and what should go in a minor.

For example, consider #11669. We support almost all of the possible interactions between private properties and optional chaining, except for that one. Is it a new feature (because we didn't support it) or a bugfix (because it's an edge case we didn't correctly implement)?
Sometimes we decide to consider things like that as bugfixes, but mark them as "new feature" to make them stand out in the changelog.

Then, there are new features that aren't exposed to our users. For example, in order to fix a bug in a plugin, we may need to add a new function to one of the @babel/helpers-* packages: it is a new feature for that specific package, but from an user perspective (or considering the project as a whole) it's just a bugfix.

I also realized that in 7.10.2's changelog there is an ESLint-related "New feature". We don't release ESLint-related packages from this repository yet, so I'm going to remove it from the changelog.

[MatthewHerbst]

Thanks for the response! As a consumer, I spend significantly more time reading feature release notes than bug fix release notes, so from my perspective, limiting features to actual consumer-facing features saves me time in having to understand what has changed.

we didn't correctly implement

I think that clearly makes it a bugfix. I've seen in some release notes spec compliance called out specifically. I think that's a good pattern and is appreciated.

there are new features that aren't exposed to our users

As a package maintainer myself I agree that's a toss-up. I've personally been marking them as minor versions still since someone could be developing on the package locally, but I don't think it's a problem to mark those as patch versions if they are small