mirror of
https://github.com/semver/semver.git
synced 2026-07-11 06:53:03 -05:00
[GH-ISSUE #223] Add #EOL #1885
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#1885
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @franz-josef-kaiser on GitHub (Sep 23, 2014).
Original GitHub issue: https://github.com/semver/semver/issues/223
Always when there is a discussion about upgrading or not (like the ones you know about PHP versions and WordPress), there's somehow no really strong argument that the people accept. So I propose a more "in-your-face" approach and clearly indicate when a version will get no more support:
This would clearly indicate that no one should use this version anymore and that there won't be any more support for that version.
Let's face it: If we have three different types of this is not ready suffix for a version, there can at least be one this is dead suffix.
@johannes-weber commented on GitHub (Sep 23, 2014):
++1
@webmozart commented on GitHub (Sep 23, 2014):
The example is ambiguous: Does this indicate the EOL of 1 or 1.1?
@franz-josef-kaiser commented on GitHub (Sep 23, 2014):
@webmozart fixed that. (copy & paste typo, EOL for patches aren't needed).
@tnorthcutt commented on GitHub (Sep 23, 2014):
@franz-josef-kaiser would it make sense then that e.g.
1.1-EOLwould indicate EOL for1.1and any1.1.xversions? Same with e.g.1-EOLand any1.xversions?@webmozart commented on GitHub (Sep 23, 2014):
@franz-josef-kaiser So that's EOL for 1.1 then? Could you add another example for 1?
@Chrico commented on GitHub (Sep 23, 2014):
+1 !
@webmozart commented on GitHub (Sep 23, 2014):
Also, since "rc" is lowercase, "eol" should be lowercase too.
@franz-josef-kaiser commented on GitHub (Sep 23, 2014):
I don't think that we would need
1-EOL. If1.5.8would be the last version,1.5.-EOLwould indicate the end of life for the whole1.xversion.Agree.
@kraftner commented on GitHub (Sep 23, 2014):
So what if
1.5.8isn't the last version for1.xbut only for1.5.x?@hikari-no-yume commented on GitHub (Sep 23, 2014):
I think this is a good idea, if the wrinkles are smoothed out.
@kraftner commented on GitHub (Sep 23, 2014):
Maybe 1.5.x-EOL to indicate end of 1.5.x branch. Could even be used to terminate the whole project: x-EOL
@hikari-no-yume commented on GitHub (Sep 23, 2014):
@kraftner I like that, it's the clearest of the proposals so far.
@webmozart commented on GitHub (Sep 23, 2014):
@kraftner 👍
@franz-josef-kaiser commented on GitHub (Sep 23, 2014):
👍
@GaryJones commented on GitHub (Sep 23, 2014):
Does the proposal still fit the ordering of versions when using
version_compare()? i.e.1.1-eol>1.1.1? How about1-eolversus1.1-eol?@hikari-no-yume commented on GitHub (Sep 23, 2014):
presumably
1.1.x-eolwould appear newer than1.1.1?@webmozart commented on GitHub (Sep 23, 2014):
Some tests with PHP's
version_compare():So the only suitable solution considering the current implementation of
version_compare()is to use the next free version number (as usual), but append-eol.@webmozart commented on GitHub (Sep 23, 2014):
The above example was for a project which maintains 1.0.x, 1.1.x and 1.2.x in parallel. If a project only maintains a single 1.x and a 2.x branch, that would probably be:
@franz-josef-kaiser commented on GitHub (Sep 23, 2014):
In addition to @webmozart , I did some test on PHP 5.5.16: All tests evalute to
TRUE.As
dev,a,alpha,b,beta,RC,rc,plandpare special chars, they work the following: Every one of them - with the exception ofpandpl- are overruled by anyint. Every patch (3rd int) overrules a two digit version number. But ...pandplalone override every other version as well. So one could as well usepeol(patch level end of life) as suffix to override everything else.@franz-josef-kaiser commented on GitHub (Sep 23, 2014):
If
-peolwould be used for "end of life", even the following works (cli test) right now. This would allow ending different levels, while the end of the major version would overrule EOL for sub versions.@FichteFoll commented on GitHub (Sep 23, 2014):
Are you guys even talking about semver? Because right now, all proposed examples violate the current spec and PHP's
version_compareis not semver-compliant at all.If you were to flag your release as "eol", use the build metadata for this like so:
1.1.1+eol.-eolwould be a pre-release and these are 1) lower in precedence than the actual version and 2) in fact only a beta release, so package managers might hide them from the public if they are configured that way.So, to be fair I think communicating the end of life status of either a project, a major or a minor is arguable and can have some use cases, but this should be possible to make with little to no changes to the current syntax. I suggest being more explicit with the following examples:
1.1.1+minor.eolmarks the eol of the1.1line.1.2.0+major.eolmarks the eol of the1line.2.0.3+eolmarks the eol of the projectWith that, we don't have to modify semver's syntax at all and it's clear how it works. If you use build metadata for other stuff already, just place it after the eol part.
@Qoto commented on GitHub (Sep 24, 2014):
Support @FitcheFoll proposal, which is more elaborated in my opinion, especially regarding the proper syntax. Having said that, I don't feel that each minor version should have
eol. I think it is more suited to mark the end of the project or the major version onlyv1.1.134+eol.m- major eolv1.1.134+eol.p- project eol@kraftner commented on GitHub (Sep 24, 2014):
We are moving somewhere and @FichteFoll proposal sounds the most reasonable until now.
Still I have one gripe with this. It works great if you already know that a release is the final one. But what if you only decide later on. Are you going to do another release with no changes just to communicate the eol? Add a second tag to the last release? I haven't really thought this through but I think this is a situation that needs to be handled as well.
@Qoto commented on GitHub (Sep 24, 2014):
@kraftner IMHO minor tag should specify eol for both major and project. The dot should be used to specify which eol is that specifically, similar to
1.0.0-rc.1.The minor tag with eol statement will be added if eol was desided later on, and will include final touches and documentation on why this tag sets eol.
@jwdonahue commented on GitHub (Dec 8, 2017):
@kraftner, yes, bump the patch level and attach the appropriate EOL meta tag as @FichteFoll suggested.
@jwdonahue commented on GitHub (Dec 8, 2017):
@franz-josef-kaiser, your proposal would be a breaking change and has a non-breaking work-around as specified by @FichteFoll. Unless you intend to produce a PR linked to this issue or have further relevant comments, please close this issue at your earliest possible convenience.