[GH-ISSUE #223] Add #EOL #4396

New Issue

GiteaMirror · 2026-06-13T12:23:23-05:00

GiteaMirror commented

2026-06-13 12:23:23 -05:00

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:

1.0.0-alpha
1.0.0-alpha.1
1.0.0-beta
1.0.0-beta.1
1.0.0-rc.1
1.0.0-rc.2
1.0.0-rc.3
1.0.0
1.0.1
1.1.0
1.1.1
1.1-EOL

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.

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](https://twitter.com/unserkaiser/status/514380418360283136) and clearly indicate when a version will get no more support: > 1.0.0-alpha > 1.0.0-alpha.1 > 1.0.0-beta > 1.0.0-beta.1 > 1.0.0-rc.1 > 1.0.0-rc.2 > 1.0.0-rc.3 > 1.0.0 > 1.0.1 > 1.1.0 > 1.1.1 > 1.1-EOL 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.

GiteaMirror closed this issue

2026-06-13 12:23:24 -05:00

GiteaMirror commented

2026-06-13 12:23:24 -05:00

@johannes-weber commented on GitHub (Sep 23, 2014):

++1

@johannes-weber commented on GitHub (Sep 23, 2014): ++1

GiteaMirror commented

2026-06-13 12:23:25 -05:00

@webmozart commented on GitHub (Sep 23, 2014):

The example is ambiguous: Does this indicate the EOL of 1 or 1.1?

@webmozart commented on GitHub (Sep 23, 2014): The example is ambiguous: Does this indicate the EOL of 1 or 1.1?

GiteaMirror commented

2026-06-13 12:23:25 -05:00

@franz-josef-kaiser commented on GitHub (Sep 23, 2014):

@webmozart fixed that. (copy & paste typo, EOL for patches aren't needed).

@franz-josef-kaiser commented on GitHub (Sep 23, 2014): @webmozart fixed that. (copy & paste typo, EOL for patches aren't needed).

GiteaMirror commented

2026-06-13 12:23:25 -05:00

@tnorthcutt commented on GitHub (Sep 23, 2014):

@franz-josef-kaiser would it make sense then that e.g. 1.1-EOL would indicate EOL for 1.1 and any 1.1.x versions? Same with e.g. 1-EOL and any 1.x versions?

@tnorthcutt commented on GitHub (Sep 23, 2014): @franz-josef-kaiser would it make sense then that e.g. `1.1-EOL` would indicate EOL for `1.1` and any `1.1.x` versions? Same with e.g. `1-EOL` and any `1.x` versions?

GiteaMirror commented

2026-06-13 12:23:26 -05:00

@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?

@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?

GiteaMirror commented

2026-06-13 12:23:26 -05:00

@Chrico commented on GitHub (Sep 23, 2014):

+1 !

@Chrico commented on GitHub (Sep 23, 2014): +1 !

GiteaMirror commented

2026-06-13 12:23:27 -05:00

@webmozart commented on GitHub (Sep 23, 2014):

Also, since "rc" is lowercase, "eol" should be lowercase too.

@webmozart commented on GitHub (Sep 23, 2014): Also, since "rc" is lowercase, "eol" should be lowercase too.

GiteaMirror commented

2026-06-13 12:23:27 -05:00

@franz-josef-kaiser commented on GitHub (Sep 23, 2014):

So that's EOL for 1.1 then? Could you add another example for 1?

would it make sense then that e.g. 1.1-EOL would indicate EOL for 1.1 and any 1.1.x versions? Same with e.g. 1-EOL and any 1.x versions?

I don't think that we would need 1-EOL. If 1.5.8 would be the last version, 1.5.-EOL would indicate the end of life for the whole 1.x version.

Also, since "rc" is lowercase, "eol" should be lowercase too.

Agree.

@franz-josef-kaiser commented on GitHub (Sep 23, 2014): > So that's EOL for 1.1 then? Could you add another example for 1? > > would it make sense then that e.g. `1.1-EOL` would indicate EOL for `1.1` and any `1.1.x` versions? Same with e.g. `1-EOL` and any `1.x` versions? I don't think that we would need `1-EOL`. If `1.5.8` would be the last version, `1.5.-EOL` would indicate the _end of life_ for the whole `1.x` version. > Also, since "rc" is lowercase, "eol" should be lowercase too. Agree.

GiteaMirror commented

2026-06-13 12:23:28 -05:00

@kraftner commented on GitHub (Sep 23, 2014):

So what if 1.5.8 isn't the last version for 1.x but only for 1.5.x?

@kraftner commented on GitHub (Sep 23, 2014): So what if `1.5.8` isn't the last version for `1.x` but only for `1.5.x`?

GiteaMirror commented

2026-06-13 12:23:28 -05:00

@hikari-no-yume commented on GitHub (Sep 23, 2014):

I think this is a good idea, if the wrinkles are smoothed out.

@hikari-no-yume commented on GitHub (Sep 23, 2014): I think this is a good idea, if the wrinkles are smoothed out.

GiteaMirror commented

2026-06-13 12:23:28 -05:00

@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

@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

GiteaMirror commented

2026-06-13 12:23:29 -05:00

@hikari-no-yume commented on GitHub (Sep 23, 2014):

@kraftner I like that, it's the clearest of the proposals so far.

@hikari-no-yume commented on GitHub (Sep 23, 2014): @kraftner I like that, it's the clearest of the proposals so far.

GiteaMirror commented

2026-06-13 12:23:29 -05:00

@webmozart commented on GitHub (Sep 23, 2014):

@kraftner 👍

@webmozart commented on GitHub (Sep 23, 2014): @kraftner :+1:

GiteaMirror commented

2026-06-13 12:23:30 -05:00

@franz-josef-kaiser commented on GitHub (Sep 23, 2014):

👍

@franz-josef-kaiser commented on GitHub (Sep 23, 2014): :+1:

GiteaMirror commented

2026-06-13 12:23:30 -05:00

@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 about 1-eol versus 1.1-eol?

@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 about `1-eol` versus `1.1-eol`?

GiteaMirror commented

2026-06-13 12:23:30 -05:00

@hikari-no-yume commented on GitHub (Sep 23, 2014):

presumably 1.1.x-eol would appear newer than 1.1.1?

@hikari-no-yume commented on GitHub (Sep 23, 2014): presumably `1.1.x-eol` would appear newer than `1.1.1`?

GiteaMirror commented

2026-06-13 12:23:31 -05:00

@webmozart commented on GitHub (Sep 23, 2014):

Some tests with PHP's version_compare():

$ php -r "var_dump(version_compare('1.1-eol', '1.1.1', '>'));"
bool(false)
$ php -r "var_dump(version_compare('1.1.x-eol', '1.1.1', '>'));"
bool(false)
$ php -r "var_dump(version_compare('1.1.1-eol', '1.1.1', '>'));"
bool(false)
$ php -r "var_dump(version_compare('1.1.2-eol', '1.1.1', '>'));"
bool(true)

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.

1.0.0-alpha
1.0.0-alpha.1
1.0.0-beta
1.0.0-beta.1
1.0.0-rc.1
1.0.0-rc.2
1.0.0-rc.3
1.0.0
1.0.1-eol
# EOL for 1.0.x
1.1.0
1.1.1
1.1.2-eol
# EOL for 1.1.x
1.2.0
1.2.1
1.2.2
1.2.3-eol
# EOL for 1.2.x
# implicitly: EOL for 1.x, since there are no more active minor versions
2.0.0
2.0.1

@webmozart commented on GitHub (Sep 23, 2014): Some tests with PHP's `version_compare()`: ``` $ php -r "var_dump(version_compare('1.1-eol', '1.1.1', '>'));" bool(false) $ php -r "var_dump(version_compare('1.1.x-eol', '1.1.1', '>'));" bool(false) $ php -r "var_dump(version_compare('1.1.1-eol', '1.1.1', '>'));" bool(false) $ php -r "var_dump(version_compare('1.1.2-eol', '1.1.1', '>'));" bool(true) ``` 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`. ``` 1.0.0-alpha 1.0.0-alpha.1 1.0.0-beta 1.0.0-beta.1 1.0.0-rc.1 1.0.0-rc.2 1.0.0-rc.3 1.0.0 1.0.1-eol # EOL for 1.0.x 1.1.0 1.1.1 1.1.2-eol # EOL for 1.1.x 1.2.0 1.2.1 1.2.2 1.2.3-eol # EOL for 1.2.x # implicitly: EOL for 1.x, since there are no more active minor versions 2.0.0 2.0.1 ```

GiteaMirror commented

2026-06-13 12:23:31 -05:00

@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:

1.0.0-alpha
1.0.0-alpha.1
1.0.0-beta
1.0.0-beta.1
1.0.0-rc.1
1.0.0-rc.2
1.0.0-rc.3
1.0.0
1.0.1
1.1.0
1.1.1
1.1.2
1.2.0
1.2.1
1.2.2
1.2.3-eol
# EOL for 1.x
2.0.0
2.0.1

@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: ``` 1.0.0-alpha 1.0.0-alpha.1 1.0.0-beta 1.0.0-beta.1 1.0.0-rc.1 1.0.0-rc.2 1.0.0-rc.3 1.0.0 1.0.1 1.1.0 1.1.1 1.1.2 1.2.0 1.2.1 1.2.2 1.2.3-eol # EOL for 1.x 2.0.0 2.0.1 ```

GiteaMirror commented

2026-06-13 12:23:31 -05:00

@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.

var_dump(
    version_compare( '0.9.99', '1.0.0', '<' ),
    version_compare( '1.0.0-dev', '1.0.0', '<' ),
    version_compare( '1.0.0-alpha', '1.0.0', '<' ),
    version_compare( '1_0_0_alpha', '1.0.0', '<' ),
    version_compare( '1+0+0_alpha', '1.0.0', '<' ),
    version_compare( '1.0.0-beta', '1.0.0', '<' ),
    version_compare( '1.0.0-b', '1.0.0', '<' ),
    version_compare( '1.0.0-rc', '1.0.0', '<' ),
    version_compare( '1.0.0-rc.0', '1.0.0-rc.1', '<' ),
    version_compare( '1.0.0-rc', '1.0.0-rc.1', '<' ),
    version_compare( '1.0.0-rc.', '1.0.0-rc.1', '<' ),
    version_compare( '1.0.0-dev', '1.0.0-alpha', '<' ),
    version_compare( '1.0.0-dev', '1.0.0-a', '<' ),
    version_compare( '1.0.0-dev', '1.0.0beta', '<' ),
    '-------------',
    version_compare( '1.0.0-pl', '1.0.0', '>' ),
    version_compare( '1.0.1', '1.0.pl1', '<' ),
    version_compare( '1.0.0-p', '1.0.0', '>' ),
    version_compare( '1.0.0-#', '1.0.0', '<' ),
    version_compare( '1.0.0', '1.0', '>' ),
    version_compare( '1.0.0-abc', '1.0.0', '<' ),
    version_compare( '1.0.0abc', '1.0.0', '<' ),
    version_compare( '1.0.0*', '1.0.0', '<' ),
    version_compare( '~1.0.0*', '1.0.0', '<' ),
    version_compare( '1.0.0-eol', '1.0.0', '<' ),
    version_compare( '1.0.0eol', '1.0.0', '<' ),
    version_compare( '1.0.0EOL', '1.0.0', '<' ),
    '-------------',
    version_compare( '1.1-eol', '1.1.1', '<' ),
    version_compare( '1eol', '1.1-eol', '<' ),
    version_compare( '1-eol', '1.1-eol', '<' ),
    version_compare( '1.x-eol', '1.1-eol', '<' ),
    '-------------',
    version_compare( 'p', 'pl', '=' ),
    version_compare( '1.1.pl', '1.1.p', '=' ),
    version_compare( '1.1-pleol', '1.1.1', '>' ),
    version_compare( '1.1.pl', '1.1.1', '>' ),
    version_compare( '1.1.p', '1.1.1', '>' ),
    version_compare( 'pl', '1.1.1', '>' ), # Interesting thing are this and the next 3 overrides
    version_compare( 'p', '1.p', '>' ),
    version_compare( 'p', '1.1.p', '>' ),
    version_compare( '1.p', '1.1.p', '>' ),
    '-------------',
    version_compare( '*', '1.5.1', '<' ),
    version_compare( '~', '1.5.1', '<' ),
    version_compare( '#', '1.5.1', '<' ),
    version_compare( 'dev', '1.5.1', '<' ),
    version_compare( 'a', '1.5.1', '<' ),
    version_compare( 'b', '1.5.1', '<' ),
    version_compare( 'dev', 'a', '<' ),
    version_compare( 'a', 'b', '<' ),
    version_compare( 'b', 'rc', '<' ),
    version_compare( 'rc', '1', '<' ),
    version_compare( '1', 'p', '<' ),
    version_compare( '1', 'peol', '<' ),
    version_compare( 'p', 'peol', '=' ),
    version_compare( 'p', 'pleol', '=' ),
    '-------------',
    version_compare( '1.5', '1.5.1', '<' ),
    version_compare( '1.5.x', '1.5.1', '<' ),
    version_compare( '1.5.z', '1.5.1', '<' ),
    version_compare( '1.5.#', '1.5.1', '<' ),
    version_compare( '1.5.*', '1.5.1', '<' ),
    version_compare( '~1.5', '1.5.1', '<' ),
    version_compare( '1.5.!', '1.5.1', '<' ),
    version_compare( '1.5.dev', '1.5.1', '<' ),
    version_compare( '1.5.a', '1.5.1', '<' ),
    version_compare( '1.5.b', '1.5.1', '<' ),
    '-------------',
    version_compare( '1.5.99', '1.5.peol', '<' ) # This is the most interesting find
);

As dev, a, alpha, b, beta, RC, rc, pl and p are special chars, they work the following: Every one of them - with the exception of p and pl - are overruled by any int. Every patch (3rd int) overrules a two digit version number. But ... p and pl alone override every other version as well. So one could as well use peol (patch level end of life) as suffix to override everything else.

@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`. ``` var_dump( version_compare( '0.9.99', '1.0.0', '<' ), version_compare( '1.0.0-dev', '1.0.0', '<' ), version_compare( '1.0.0-alpha', '1.0.0', '<' ), version_compare( '1_0_0_alpha', '1.0.0', '<' ), version_compare( '1+0+0_alpha', '1.0.0', '<' ), version_compare( '1.0.0-beta', '1.0.0', '<' ), version_compare( '1.0.0-b', '1.0.0', '<' ), version_compare( '1.0.0-rc', '1.0.0', '<' ), version_compare( '1.0.0-rc.0', '1.0.0-rc.1', '<' ), version_compare( '1.0.0-rc', '1.0.0-rc.1', '<' ), version_compare( '1.0.0-rc.', '1.0.0-rc.1', '<' ), version_compare( '1.0.0-dev', '1.0.0-alpha', '<' ), version_compare( '1.0.0-dev', '1.0.0-a', '<' ), version_compare( '1.0.0-dev', '1.0.0beta', '<' ), '-------------', version_compare( '1.0.0-pl', '1.0.0', '>' ), version_compare( '1.0.1', '1.0.pl1', '<' ), version_compare( '1.0.0-p', '1.0.0', '>' ), version_compare( '1.0.0-#', '1.0.0', '<' ), version_compare( '1.0.0', '1.0', '>' ), version_compare( '1.0.0-abc', '1.0.0', '<' ), version_compare( '1.0.0abc', '1.0.0', '<' ), version_compare( '1.0.0*', '1.0.0', '<' ), version_compare( '~1.0.0*', '1.0.0', '<' ), version_compare( '1.0.0-eol', '1.0.0', '<' ), version_compare( '1.0.0eol', '1.0.0', '<' ), version_compare( '1.0.0EOL', '1.0.0', '<' ), '-------------', version_compare( '1.1-eol', '1.1.1', '<' ), version_compare( '1eol', '1.1-eol', '<' ), version_compare( '1-eol', '1.1-eol', '<' ), version_compare( '1.x-eol', '1.1-eol', '<' ), '-------------', version_compare( 'p', 'pl', '=' ), version_compare( '1.1.pl', '1.1.p', '=' ), version_compare( '1.1-pleol', '1.1.1', '>' ), version_compare( '1.1.pl', '1.1.1', '>' ), version_compare( '1.1.p', '1.1.1', '>' ), version_compare( 'pl', '1.1.1', '>' ), # Interesting thing are this and the next 3 overrides version_compare( 'p', '1.p', '>' ), version_compare( 'p', '1.1.p', '>' ), version_compare( '1.p', '1.1.p', '>' ), '-------------', version_compare( '*', '1.5.1', '<' ), version_compare( '~', '1.5.1', '<' ), version_compare( '#', '1.5.1', '<' ), version_compare( 'dev', '1.5.1', '<' ), version_compare( 'a', '1.5.1', '<' ), version_compare( 'b', '1.5.1', '<' ), version_compare( 'dev', 'a', '<' ), version_compare( 'a', 'b', '<' ), version_compare( 'b', 'rc', '<' ), version_compare( 'rc', '1', '<' ), version_compare( '1', 'p', '<' ), version_compare( '1', 'peol', '<' ), version_compare( 'p', 'peol', '=' ), version_compare( 'p', 'pleol', '=' ), '-------------', version_compare( '1.5', '1.5.1', '<' ), version_compare( '1.5.x', '1.5.1', '<' ), version_compare( '1.5.z', '1.5.1', '<' ), version_compare( '1.5.#', '1.5.1', '<' ), version_compare( '1.5.*', '1.5.1', '<' ), version_compare( '~1.5', '1.5.1', '<' ), version_compare( '1.5.!', '1.5.1', '<' ), version_compare( '1.5.dev', '1.5.1', '<' ), version_compare( '1.5.a', '1.5.1', '<' ), version_compare( '1.5.b', '1.5.1', '<' ), '-------------', version_compare( '1.5.99', '1.5.peol', '<' ) # This is the most interesting find ); ``` As `dev`, `a`, `alpha`, `b`, `beta`, `RC`, `rc`, `pl` and `p` are special chars, they work the following: Every one of them - with the exception of `p` and `pl` - are overruled by any `int`. Every patch (3rd int) overrules a two digit version number. _But_ ... `p` and `pl` alone override _every_ other version as well. So one could as well use `peol` (patch level end of life) as suffix to override everything else.

GiteaMirror commented

2026-06-13 12:23:32 -05:00

@franz-josef-kaiser commented on GitHub (Sep 23, 2014):

If -peol would 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.

$ php -r "var_dump( version_compare( '1.1.1', '1.1.peol', '<' ) );"
bool(true)
$ php -r "var_dump( version_compare( '1.1.1', '1.peol', '<' ) );"
bool(true)
$ php -r "var_dump( version_compare( '1', '1.peol', '<' ) );"
bool(true)
$ php -r "var_dump( version_compare( '1.9', '1.peol', '<' ) );"
bool(true)
$ php -r "var_dump( version_compare( '1.9.99', '1.peol', '<' ) );"
bool(true)
$ php -r "var_dump( version_compare( '1.9-p', '1-peol', '<' ) );"
bool(true)
$ php -r "var_dump( version_compare( '1.9-pl', '1-peol', '<' ) );"
bool(true)
$ php -r "var_dump( version_compare( '1.9-peol', '1-peol', '<' ) );"
bool(true)

@franz-josef-kaiser commented on GitHub (Sep 23, 2014): If `-peol` would 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. ``` $ php -r "var_dump( version_compare( '1.1.1', '1.1.peol', '<' ) );" bool(true) $ php -r "var_dump( version_compare( '1.1.1', '1.peol', '<' ) );" bool(true) $ php -r "var_dump( version_compare( '1', '1.peol', '<' ) );" bool(true) $ php -r "var_dump( version_compare( '1.9', '1.peol', '<' ) );" bool(true) $ php -r "var_dump( version_compare( '1.9.99', '1.peol', '<' ) );" bool(true) $ php -r "var_dump( version_compare( '1.9-p', '1-peol', '<' ) );" bool(true) $ php -r "var_dump( version_compare( '1.9-pl', '1-peol', '<' ) );" bool(true) $ php -r "var_dump( version_compare( '1.9-peol', '1-peol', '<' ) );" bool(true) ```

GiteaMirror commented

2026-06-13 12:23:32 -05:00

@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_compare is 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. -eol would 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.eol marks the eol of the 1.1 line.
1.2.0+major.eol marks the eol of the 1 line.
2.0.3+eol marks the eol of the project

With 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.

@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_compare` is _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`. `-eol` would 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.eol` marks the eol of the `1.1` line. - `1.2.0+major.eol` marks the eol of the `1` line. - `2.0.3+eol` marks the eol of the project With 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.

GiteaMirror commented

2026-06-13 12:23:33 -05:00

@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 only

v1.1.134+eol.m - major eol
v1.1.134+eol.p - project eol

@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 only `v1.1.134+eol.m` - major eol `v1.1.134+eol.p` - project eol

GiteaMirror commented

2026-06-13 12:23:33 -05:00

@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.

@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.

GiteaMirror commented

2026-06-13 12:23:33 -05:00

@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.

@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.

GiteaMirror commented

2026-06-13 12:23:34 -05:00

@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): @kraftner, yes, bump the patch level and attach the appropriate EOL meta tag as @FichteFoll [suggested](https://github.com/semver/semver/issues/223#issuecomment-56538560).

GiteaMirror commented

2026-06-13 12:23:34 -05:00

@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.

@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](https://github.com/semver/semver/issues/223#issuecomment-56538560). 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.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#4396