A more strict semver policy

[mcollina]

It happened already a couple of times in the 5.x.x series that our build broke because of a new minor release. I know we all make mistakes, but I love depending on standard using ^. Problems like this almost never happened in the 4.x.x series.

I know these are changing times with all the evolution of core, so let me know how I can help making this a little more reliable across versions.

[mcollina]

Sorry for complaining about this, but one of the main selling point of standard is being frictionless. Broken builds create friction :(.

[dcousens]

The amount of times this has come up in conversation over the last few days with several project owners whom I had referred standard.
They love it, but the build breaking was very frustrating for them, and its only been realized a few weeks later.

Most of it has been in regards to the fixes applied in #170.
We were technically adhering to semver, its just everyone had become reliant on the broken behaviour of it not throwing.

[dcousens]

I can't help but think this entire situation smells of:

[mcollina]

I am proposing a slightly stricter semver: if anything would break users builds, we bump the major. If we made a mistake and we do break user builds (and that's fine!) we just remove that release, and re-release on a bumped major.

[feross]

@mcollina

For a linter, any change, even in dependencies, has a decent potential to break someone's tests.

For example, eslint publishes patch versions when they improve a rule to detect some case that was being missed before. This makes sense to be a patch from their perspective, since it's a bugfix – the rule wasn't working correctly before.

But to end users, that patch version could cause eslint to start failing on code that passed before. This isn't theoretical – they release changes like this in every patch version.

This bit from the jscs project is relevant: https://github.com/jscs-dev/node-jscs/blob/master/OVERVIEW.md#versioning--semver Note that they introduce bug fixes that cause more errors to be reported in minor versions.

So, to be safe, literally every time we bump a dep, we would need to publish a major version. I don't think this is realistic. (I propose continuing as before with regards to updating dependencies).

There's also another question: What should we do when we intended to catch certain cases but weren't, for whatever reason. When we add a new rule or make a rule change to catch that case – what semver should that be? We've been publishing these as minor, which is what has caused all this recent pain. (I propose these should be major version bumps going forward).

It seems that in practice the source of build breakage has been our intentional rule changes, not the eslint bugfixes.

[mcollina]

Thanks @feross for the long response, and for the willingness to discuss such a delicate topic 👍.

I know doing a project where the simplicity of usage is major value proposition is extremely hard as soon as its gets adopted. Balancing stability and innovation is really hard.

As you mentioned, depending with ^ was suddenly causing a lot of instability. Just to clarify, I am not speaking about OSS projects here, but more about continuos deployment scenarios that I face in my day to day work. I was not aware of JSCS readme definitions, and I think that is a good rule, so we should probably add it to README in this project as well. Moreover, we should add a FAQ that explains it clearly, like "What to do if your building are suddenly failing? If you are in a continuous deployment setup, you should depend on it using ~". I can send a PR if you want.

Regarding dependencies, another completely different solution to this problem is to use shrinkwrap. I fear that might cause too much work to keep everything updated. What do you think?

On a side note, the README is quite long, what about adding an index at the top like levelup?