[GH-ISSUE #212] No rule to define package deprecation or end of life #6131

New Issue

GiteaMirror · 2026-06-17T04:40:23-05:00

GiteaMirror commented

2026-06-17 04:40:23 -05:00

Originally created by @hparra on GitHub (Jul 18, 2014).
Original GitHub issue: https://github.com/semver/semver/issues/212

There is no rule to mark an entire package as deprecated or end of life (EOL).

Such a semver would be useful to communicate one or more or the following:

the package has been superseded by another package
the package is no longer developed or maintained
the package parent software or system is obsolete

Proposed grammar:

<valid semver> ::= <version core>
                 | <version core> "-EOL"
                 ... etc.

Not sure if -final is more or less appropriate. I don't have a strong opinion regarding casing.

I'm willing to propose or collaborate on language to produce PR.

Originally created by @hparra on GitHub (Jul 18, 2014). Original GitHub issue: https://github.com/semver/semver/issues/212 There is no rule to mark an entire package as deprecated or end of life (EOL). Such a semver would be useful to communicate one or more or the following: - the package has been superseded by another package - the package is no longer developed or maintained - the package parent software or system is obsolete Proposed grammar: ``` <valid semver> ::= <version core> | <version core> "-EOL" ... etc. ``` Not sure if `-final` is more or less appropriate. I don't have a strong opinion regarding casing. I'm willing to propose or collaborate on language to produce PR.

GiteaMirror closed this issue

2026-06-17 04:40:23 -05:00

GiteaMirror commented

2026-06-17 04:40:24 -05:00

@FichteFoll commented on GitHub (Jul 18, 2014):

I do not think this should be part of the version number and rather be handled by the respective package manager.

@FichteFoll commented on GitHub (Jul 18, 2014): I do not think this should be part of the version number and rather be handled by the respective package manager.

GiteaMirror commented

2026-06-17 04:40:25 -05:00

@tomByrer commented on GitHub (Sep 19, 2014):

In 2 of the 3 scenarios above, it is unlikely there will be a response to outside PRs. Like Fichte said, the PM could add a note in the metadata: 2.9.0+eol. Perhaps that use-case for metadata can be mentioned in the doc?

@tomByrer commented on GitHub (Sep 19, 2014): In 2 of the 3 scenarios above, it is unlikely there will be a response to outside PRs. Like Fichte said, the PM could add a note in the metadata: `2.9.0+eol`. Perhaps that use-case for metadata can be mentioned in the doc?

GiteaMirror commented

2026-06-17 04:40:25 -05:00

@jwdonahue commented on GitHub (Dec 6, 2017):

Perhaps an EOL tag, could be added that begins with something other than the prerelease tag mark? My view is that build meta should be renamed user data and any semantics, ordering or internal syntax should be left up to the implementer. Putting EOL in the prerelease tag would be useless because it would have lower precedence than whatever the last non-prerelease version was.

@hparra, if you are not planning on issuing a PR with proposed changes, please close this issue at your earliest possible convenience. It seems unlikely that any new fields would be accepted into the standard. Perhaps if the maintainers ever decide to open a 3.x.x branch this issue could be revived then?

@jwdonahue commented on GitHub (Dec 6, 2017): Perhaps an EOL tag, could be added that begins with something other than the prerelease tag mark? My view is that build meta should be renamed user data and any semantics, ordering or internal syntax should be left up to the implementer. Putting EOL in the prerelease tag would be useless because it would have lower precedence than whatever the last non-prerelease version was. @hparra, if you are not planning on issuing a PR with proposed changes, please close this issue at your earliest possible convenience. It seems unlikely that any new fields would be accepted into the standard. Perhaps if the maintainers ever decide to open a 3.x.x branch this issue could be revived then?

GiteaMirror commented

2026-06-17 04:40:25 -05:00

@jwdonahue commented on GitHub (Oct 8, 2018):

@hparra, can you please close this issue? It's not getting any traction.

@jwdonahue commented on GitHub (Oct 8, 2018): @hparra, can you please close this issue? It's not getting any traction.

GiteaMirror commented

2026-06-17 04:40:26 -05:00

@steveklabnik commented on GitHub (Feb 11, 2019):

I do not think this should be part of the version number and rather be handled by the respective package manager.

This is the answer. Semver versions and releases are immutable, so mutating the version string doesn't work. This kind of thing is outside of the purview of semver, and is a job for the particular package manager.

Thanks!

@steveklabnik commented on GitHub (Feb 11, 2019): > I do not think this should be part of the version number and rather be handled by the respective package manager. This is the answer. Semver versions and releases are immutable, so mutating the version string doesn't work. This kind of thing is outside of the purview of semver, and is a job for the particular package manager. Thanks!

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#6131