Discriminate two distinct "unstable" statuses. #578

New Issue

GiteaMirror · 2026-02-17T12:13:40-06:00

GiteaMirror commented

2026-02-17 12:13:40 -06:00

Originally created by @iago-lito on GitHub (Mar 2, 2023).

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?

Originally created by @iago-lito on GitHub (Mar 2, 2023). I liked this [short blog post take on stability](https://matklad.github.io/2023/02/16/three-state-stability.html) (@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?

GiteaMirror commented

2026-02-17 12:13:41 -06:00

@ljharb commented on GitHub (Mar 2, 2023):

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.

@ljharb commented on GitHub (Mar 2, 2023): > 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.

GiteaMirror commented

2026-02-17 12:13:41 -06:00

@jwdonahue commented on GitHub (Mar 7, 2023):

@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 commented on GitHub (Mar 7, 2023): @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?

GiteaMirror commented

2026-02-17 12:13:41 -06:00

@jwdonahue commented on GitHub (Mar 8, 2023):

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.

@jwdonahue commented on GitHub (Mar 8, 2023): > 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.

GiteaMirror commented

2026-02-17 12:13:42 -06:00

@12159050 commented on GitHub (Jun 22, 2024):

bc17e4ea2cd0002a5ef6d27eadb44af0e02b34ab

@12159050 commented on GitHub (Jun 22, 2024): bc17e4ea2cd0002a5ef6d27eadb44af0e02b34ab

GiteaMirror referenced this issue

2026-02-17 12:19:42 -06:00

[PR #578] [MERGED] feat: Added linter and workflow; Fixed linter warnings #821

Sign in to join this conversation.