Discriminate two distinct "unstable" statuses.

[iago-lito]

I liked this short blog post take on stability (@matklad). Should this viewpoint ever become widespread, and people would be willing to reify this into formal SemVer, then I figured it would require some breaking change into something akin to SemVer 3.0:

• 0.x.y : experimental version : unstable, not fit for production, uncertain to even last.
• 1.x.y: production ready version : unstable, fit for production provided you upgrade.
• 2.x.y: stable.

This sounds crazy. My question is: how much crazy does this sound?
For a start, by breaking SemVer, this would break the semantics of all SemVer-compliant version numbers so far.. unless we can consider that it's just correctly re-labelling a common current usage?

[ljharb]

how much

infinity? if it's unstable it can't be fit for production, and prereleases exist already to cover that very tiny gray area.

[jwdonahue]

@iago-lito that's not the same semantics as SemVer. You could distinguish it from SemVer like this:

• E.x.y : experimental version : unstable, not fit for production, uncertain to even last.
• U.x.y: production ready version : unstable, fit for production provided you upgrade.
• S.x.y: stable.

But it's not a reasonable scheme. All three categories are subjective and the last one is essentially a promise not to stay up to date on your dependencies, if any, so we should relabel it with an 'R' for rotting. Many publishers stop rolling bug fixes into older major versions. If you want to keep your product secure, you pretty much have to pay the cost of taking breaking changes in your dependency tree and that generally forces you to issue major version bumps on your product.

So rather than breaking the current semantics, you should be looking to extend them gracefully. All four categories will vary substantially in quality. Stability is one among many dimensions of quality. So maybe you add a tag that indicates the level of testing (Full/partial suite of acceptance, integration and unit tests, coverage rates, size and length of betas), the number of known unfixed issues, intended future rate of change, etc.

But wait! SemVer already allows for that in the meta tag, so you could propose a convention for stating those metrics concisely in the +meta tag?

[jwdonahue]

But wait! SemVer already allows for that in the meta tag, so you could propose a convention for stating those metrics concisely in the +meta tag?

If only we could get certain package sites to at least store the meta tags and allow us to filter on them.