[GH-ISSUE #205] SemVer needs to define Version Range Spec syntax/behavior #7111

New Issue

GiteaMirror · 2026-06-20T16:52:09-05:00

GiteaMirror commented

2026-06-20 16:52:09 -05:00

Originally created by @jeffhandley on GitHub (Jul 1, 2014).
Original GitHub issue: https://github.com/semver/semver/issues/205

There are many ways to write out version range specs that control what version of software will be referenced. The SemVer spec doesn't currently declare how range specs against SemVer versions should be written or how they should behave. I think this is a gap in the spec that is becoming more apparent and necessary to fill.

Issue #200 is a notable issue where this has come up. Issue #172 is another, where there was a proposal to add 'SNAPSHOT' support into the spec. The 'SNAPSHOT' version is actually one that the consumer knows about but the software itself never actually marks a version as the 'SNAPSHOT'. It's behavior of how to specify that you want to reference a dynamic version number, giving a hint for which version to select.

There are many different approaches for specifying the referenced version. I propose that we augment the SemVer spec to declare a standard version range syntax with behaviors clearly defined as well.

Originally created by @jeffhandley on GitHub (Jul 1, 2014). Original GitHub issue: https://github.com/semver/semver/issues/205 There are many ways to write out version range specs that control what version of software will be referenced. The SemVer spec doesn't currently declare how range specs against SemVer versions should be written or how they should behave. I think this is a gap in the spec that is becoming more apparent and necessary to fill. Issue #200 is a notable issue where this has come up. Issue #172 is another, where there was a proposal to add 'SNAPSHOT' support into the spec. The 'SNAPSHOT' version is actually one that the consumer knows about but the software itself never actually marks a version as the 'SNAPSHOT'. It's behavior of how to specify that you want to reference a dynamic version number, giving a hint for which version to select. There are many different approaches for specifying the referenced version. I propose that we augment the SemVer spec to declare a standard version range syntax with behaviors clearly defined as well.

GiteaMirror added the question staled labels 2026-06-20 16:52:09 -05:00

GiteaMirror closed this issue

2026-06-20 16:52:10 -05:00

GiteaMirror commented

2026-06-20 16:52:12 -05:00

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

I just spent some time deriving my older standard for semantic version selectors (which I'm gonna call semsel from now on) to the new things I've been thinking about in the mean time. It covers every reasonable use case I can currently think of and the explanations are kind of verbose, but that's better than being unclear. However, it does not cover post-releases (#200).

I didn't want to include the whole draft here, so check them out at https://gist.github.com/FichteFoll/a93e064468a6d9b14ea2 and leave some feedback if you were so kind.

@FichteFoll commented on GitHub (Jul 1, 2014): I just spent some time deriving my older standard for semantic version selectors (which I'm gonna call semsel from now on) to the new things I've been thinking about in the mean time. It covers every reasonable use case I can currently think of and the explanations are kind of verbose, but that's better than being unclear. However, it does not cover post-releases (#200). I didn't want to include the whole draft here, so check them out at https://gist.github.com/FichteFoll/a93e064468a6d9b14ea2 and leave some feedback if you were so kind.

GiteaMirror commented

2026-06-20 16:52:12 -05:00

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

I discovered draftin today and pasted my draft there too. Feel free to do any changes (they appear as pull requests) or add comments to sections:

https://draftin.com/documents/375100?token=rR30GmJJzi4l3BRlD-cHs8lcAcdDAXH4oTzqOWeL0CT0BNv3PZEx0g8pBkI13sQgYXTBqShZ0Ucsqek3Fn3d-aU

@FichteFoll commented on GitHub (Jul 4, 2014): I discovered draftin today and pasted my draft there too. Feel free to do any changes (they appear as pull requests) or add comments to sections: https://draftin.com/documents/375100?token=rR30GmJJzi4l3BRlD-cHs8lcAcdDAXH4oTzqOWeL0CT0BNv3PZEx0g8pBkI13sQgYXTBqShZ0Ucsqek3Fn3d-aU

GiteaMirror commented

2026-06-20 16:52:13 -05:00

@jeffhandley commented on GitHub (Jul 9, 2014):

I haven't been able to look at what you proposed in detail yet, but it's a lot more involved than what I was anticipating. I don't know if that's good or bad, it just is.

I was thinking more along the lines of what we see package managers use today:

[5.0.0,6.0.0) to mean "greater than or equal to 5.0.0 and less than 6.0.0"
[5.0.0] to mean "exactly 5.0.0"

Where NuGet has struggled a bit is when you take those ranges and mix in prerelease versions:

Should 5.0.0-alpha satisfy "greater than or equal to 5.0.0"? According to the current spec, it should (but NuGet doesn't, which I consider to be a bug).
How can you clearly state when prerelease is acceptable vs. when it is not?

I'll have to review what you're proposing though and think about which operators a package would use within its dependency declarations vs. which operators are needed for the end user of the package manager. I'm hoping @Haacked can weigh in on this too.

@jeffhandley commented on GitHub (Jul 9, 2014): I haven't been able to look at what you proposed in detail yet, but it's a lot more involved than what I was anticipating. I don't know if that's good or bad, it just is. I was thinking more along the lines of what we see package managers use today: - `[5.0.0,6.0.0)` to mean "greater than or equal to 5.0.0 and less than 6.0.0" - `[5.0.0]` to mean "exactly 5.0.0" Where NuGet has struggled a bit is when you take those ranges and mix in prerelease versions: - Should `5.0.0-alpha` satisfy "greater than or equal to 5.0.0"? According to the current spec, it should (but NuGet doesn't, which I consider to be a bug). - How can you clearly state when prerelease is acceptable vs. when it is not? I'll have to review what you're proposing though and think about which operators a package would use within its dependency declarations vs. which operators are needed for the end user of the package manager. I'm hoping @Haacked can weigh in on this too.

GiteaMirror commented

2026-06-20 16:52:14 -05:00

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

I was thinking more along the lines of what we see package managers use today:

Well, that's too simple imo.

Should 5.0.0-alpha satisfy "greater than or equal to 5.0.0"? According to the current spec, it should (but NuGet doesn't, which I consider to be a bug).

No, it should not. Actually, no pre-release versions are matched by default at all, you have to explicitly enable that. I made it so you have to append a hyphen to the specifier, like 5.0.0- in which case you would match 5.0.0-alpha as well as 5.0.0.

The only thing I have not yet decided on (and which isn't exactly specified in the spec either) is whether >=1.0.0- should match pre-releases of 1.0.0 or not.

@FichteFoll commented on GitHub (Jul 9, 2014): > I was thinking more along the lines of what we see package managers use today: Well, that's too simple imo. > - Should 5.0.0-alpha satisfy "greater than or equal to 5.0.0"? According to the current spec, it should (but NuGet doesn't, which I consider to be a bug). No, it should not. Actually, no pre-release versions are matched by default at all, you have to explicitly enable that. I made it so you have to append a hyphen to the specifier, like `5.0.0-` in which case you would match 5.0.0-alpha as well as 5.0.0. The only thing I have not yet decided on (and which isn't exactly specified in the spec either) is whether `>=1.0.0-` should match pre-releases of 1.0.0 or not.

GiteaMirror commented

2026-06-20 16:52:14 -05:00

@jeffhandley commented on GitHub (Jul 9, 2014):

Oh, somehow I missed (or forgot) that the verbiage around pre-release versions changed between 2.0.0-rc.2 and 2.0.0.

2.0.0-rc.2 Verbiage

Pre-release versions satisfy but have a lower precedence than the associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

2.0.0 Verbiage

A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.

@jeffhandley commented on GitHub (Jul 9, 2014): Oh, somehow I missed (or forgot) that the verbiage around pre-release versions changed between `2.0.0-rc.2` and `2.0.0`. ### 2.0.0-rc.2 Verbiage > Pre-release versions satisfy but have a lower precedence than the associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92. ### 2.0.0 Verbiage > A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.

GiteaMirror commented

2026-06-20 16:52:15 -05:00

@zafarkhaja commented on GitHub (Jul 10, 2014):

The discussion of the SemVer ranges has been already started in #113.
I think we should join forces with each other.

P.S. Personally I prefer to call it SemVer expressions rather than SemVer ranges because sometimes in my implementation it's not a range but a single value, for instance 1.0.0 or =1.0.0 or !(2.0).

@zafarkhaja commented on GitHub (Jul 10, 2014): The discussion of the SemVer ranges has been already started in #113. I think we should join forces with each other. P.S. Personally I prefer to call it SemVer expressions rather than SemVer ranges because sometimes in my implementation it's not a range but a single value, for instance `1.0.0` or `=1.0.0` or `!(2.0)`.

GiteaMirror commented

2026-06-20 16:52:16 -05:00

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

"Semantic Version Selectors" is my favorite.

@FichteFoll commented on GitHub (Jul 10, 2014): "Semantic Version Selectors" is my favorite.

GiteaMirror commented

2026-06-20 16:52:16 -05:00

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

@Haacked (from gist comment)

My vote would be to adopt an existing standard unless there's good reason not to. http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html

Firstly, let's do the discussion here because I don't get notifications from gists, and likely nobody else does.

Secondly, I consider the ()[] ranges, which are actually sets, rather inconvenient and I prefer the usage >=1.0 to express truth instead of using an implicit in [1.0). Furthermore, they do not allow more complex specifiers such as >=1 !1.2.3.

Either way, we could theoretically add these sets to the spec easily since they can be translated to standard comparators. Selecting pre-releases would probably work similarly by appending - to the set.

Another idea I just had, inspired by #113, is to replace x - y version specifiers with this set notation. I can see that work and it would be compatible with maven's notation for instance. In that case we could even allow half-empty sets like [1.0,) just to make the spec more compatible, which I was initially against. What I don't like however is using commas for or chunks. I think they are way to unnoticable compared to ||.

@zafarkhaja, #113 has a bad title though, no wonder it couldn't be found.

Everything suggested in this comment is also available in my spec, except for parenthesis which I consider too much of a hassle implementation-wise and would be very rarely used I think. Same reason why ! is not just a binary NOT operator, since you can easily negate all comparators by hand.

I also agree that these selectors should not just be embedded into the semver spec but rather be decoupled and referenced.

Otherwise, that issue doesn't contain any other useful information.

@FichteFoll commented on GitHub (Jul 10, 2014): @Haacked (from [gist comment](https://gist.github.com/FichteFoll/a93e064468a6d9b14ea2#comment-1260768)) > My vote would be to adopt an existing standard unless there's good reason not to. http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html Firstly, let's do the discussion here because I don't get notifications from gists, and likely nobody else does. Secondly, I consider the `()[]` ranges, which are actually sets, rather inconvenient and I prefer the usage `>=1.0` to express truth instead of using an implicit `in [1.0)`. Furthermore, they do not allow more complex specifiers such as `>=1 !1.2.3`. Either way, we could theoretically add these sets to the spec easily since they can be translated to standard comparators. Selecting pre-releases would probably work similarly by appending `-` to the set. Another idea I just had, inspired by #113, is to replace `x - y` version specifiers with this set notation. I can see that work and it would be compatible with maven's notation for instance. In that case we could even allow half-empty sets like `[1.0,)` just to make the spec more compatible, which I was initially against. What I don't like however is using commas for _or chunks_. I think they are way to unnoticable compared to `||`. --- @zafarkhaja, #113 has a bad title though, no wonder it couldn't be found. Everything suggested in [this comment](https://github.com/mojombo/semver/issues/113#issuecomment-19347872) is also available in my spec, except for parenthesis which I consider too much of a hassle implementation-wise and would be very rarely used I think. Same reason why `!` is not just a binary NOT operator, since you can easily negate all comparators by hand. I also agree that these selectors should not just be embedded into the semver spec but rather be decoupled and referenced. Otherwise, that issue doesn't contain any other useful information.

GiteaMirror commented

2026-06-20 16:52:17 -05:00

@rlidwka commented on GitHub (Jul 10, 2014):

Imho, just use Ruby spec:

 Specification From  ... To (exclusive)
  ">= 3.0"      3.0   ... &infin;
  "~> 3.0"      3.0   ... 4.0
  "~> 3.0.0"    3.0.0 ... 3.1
  "~> 3.5"      3.5   ... 4.0
  "~> 3.5.0"    3.5.0 ... 3.6

@rlidwka commented on GitHub (Jul 10, 2014): Imho, just use Ruby [spec](http://guides.rubygems.org/patterns/#pessimistic_version_constraint): ``` Specification From ... To (exclusive) ">= 3.0" 3.0 ... ∞ "~> 3.0" 3.0 ... 4.0 "~> 3.0.0" 3.0.0 ... 3.1 "~> 3.5" 3.5 ... 4.0 "~> 3.5.0" 3.5.0 ... 3.6 ```

GiteaMirror commented

2026-06-20 16:52:18 -05:00

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

I think we can argue whether it should be ~ or ~>. I'm neutral on this. The first is shorter but the second is explicit and shows clearly that ~>1.3 does not match 1.2.0.

Rubygems aren't compatible though because they don't enforce semver.

@FichteFoll commented on GitHub (Jul 10, 2014): I think we can argue whether it should be `~` or `~>`. I'm neutral on this. The first is shorter but the second is explicit and shows clearly that `~>1.3` does not match 1.2.0. Rubygems aren't compatible though because they don't enforce semver.

GiteaMirror commented

2026-06-20 16:52:18 -05:00

@rlidwka commented on GitHub (Jul 10, 2014):

Rubygems aren't compatible though because they don't enforce semver.

Semver isn't a version mask. Semver is a policy to manage version numbers. It can't be enforced with a computer program.

@rlidwka commented on GitHub (Jul 10, 2014): > Rubygems aren't compatible though because they don't enforce semver. Semver isn't a version mask. Semver is a policy to manage version numbers. It can't be enforced with a computer program.

GiteaMirror commented

2026-06-20 16:52:19 -05:00

@EddieGarmon commented on GitHub (Jul 14, 2014):

I recommend that the mathematical range tokens [, ], (, and ) be used.

i.e. [1.2.3, 2) 
meaning >=1.2.3 and <2.0.0

and that we have a '+' shorthand for forward compat only.

i.e. 1.2+.3
meaning >=1.2.3 and <2.0
i.e. 1.2.3+
meaning >=1.2.3 and <1.3.0

@EddieGarmon commented on GitHub (Jul 14, 2014): I recommend that the mathematical range tokens [, ], (, and ) be used. ``` i.e. [1.2.3, 2) meaning >=1.2.3 and <2.0.0 ``` and that we have a '+' shorthand for forward compat only. ``` i.e. 1.2+.3 meaning >=1.2.3 and <2.0 i.e. 1.2.3+ meaning >=1.2.3 and <1.3.0 ```

GiteaMirror commented

2026-06-20 16:52:20 -05:00

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

Okay, I'll add the set syntax as an alternative for the basic comperators. However, spaces won't be allowed.

1.2.3+ is confusing imo. It is not clear whether this only increases 3 or the whole version (meaning everything from 1.2.3 and onwards). But it's especially confusing because metadata is also denoted with the plus sign.

@FichteFoll commented on GitHub (Jul 14, 2014): Okay, I'll add the set syntax as an alternative for the basic comperators. However, spaces won't be allowed. `1.2.3+` is confusing imo. It is not clear whether this only increases 3 or the whole version (meaning everything from 1.2.3 and onwards). But it's especially confusing because metadata is also denoted with the plus sign.

GiteaMirror commented

2026-06-20 16:52:20 -05:00

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

Added sets to the specs. I also added a To be specified section to the document which outlines things that I have not decided on/am unsure about. Input appreciated.

gist and draft above have been updated, for the exact changes, check revisions.

@FichteFoll commented on GitHub (Jul 17, 2014): Added sets to the specs. I also added a _To be specified_ section to the document which outlines things that I have not decided on/am unsure about. Input appreciated. gist and draft above have been updated, for the exact changes, check [revisions](https://gist.github.com/FichteFoll/a93e064468a6d9b14ea2/revisions).

GiteaMirror commented

2026-06-20 16:52:21 -05:00

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

@jeffhandley

I have gone back and forth on this one ever since my first non-trivial implementation of a tool that consumes and produces SemVer compliant strings. Initially I had a strong desire to see it in a spec somewhere, but not today.

I think the SemVer spec should not get into range specifiers, which seems more like a tool chain implementation detail to me. Defining selectors for SemVer within the SemVer spec would be a bit like Intel defining which C++ operators were legal on their machines. As long SemVer has well defined ordering semantics, the rest can be dealt with either as a separate standard or just left to implementations to define.

Keep in mind, that there may be opportunities in some languages to simply use built-in operators. What about packaging tools that already have their own set of range selectors over their own version formats? It may be easier to drive version string format changes to make existing packaging tools more compliant with SemVer, if they are not also expected to adopt new selector operators.

I for one, want to be able to advertise SemVer compliance while maintaining as much freedom of design choices as possible. Let's take the various selector concepts and describe them properly in some engineering notes that can be accessed from semver.org and not clutter up a perfectly simple standard.

@jwdonahue commented on GitHub (Dec 6, 2017): @jeffhandley I have gone back and forth on this one ever since my first non-trivial implementation of a tool that consumes and produces SemVer compliant strings. Initially I had a strong desire to see it in a spec somewhere, but not today. I think the SemVer spec should not get into range specifiers, which seems more like a tool chain implementation detail to me. Defining selectors for SemVer within the SemVer spec would be a bit like Intel defining which C++ operators were legal on their machines. As long SemVer has well defined ordering semantics, the rest can be dealt with either as a separate standard or just left to implementations to define. Keep in mind, that there may be opportunities in some languages to simply use built-in operators. What about packaging tools that already have their own set of range selectors over their own version formats? It may be easier to drive version string format changes to make existing packaging tools more compliant with SemVer, if they are not also expected to adopt new selector operators. I for one, want to be able to advertise SemVer compliance while maintaining as much freedom of design choices as possible. Let's take the various selector concepts and describe them properly in some engineering notes that can be accessed from semver.org and not clutter up a perfectly simple standard.

GiteaMirror commented

2026-06-20 16:52:22 -05:00

@FichteFoll commented on GitHub (Dec 9, 2017):

I also mentioned this before, but let me state again that SemVer and a range selection syntax for semantic versions should be separate. Of course, the latter depends on the former, so it probably needs to be updated whenever the former is, but that's insignificant.

This issue (and my draft) haven't seen any attention in recent time iirc, but imo this is still an area that could (or should, rather) be tackled and referenced on semver.org. It will not be the only standard for specifying semantic version ranges, but we should aim to be the de facto standard. Just like semver is not the only versioning scheme but a very popular one.

Since it's been over three years since this issue (and the draft) have been worked on, we should take another look at the various selectors other tooling software has implemented and weight their options depending on usability, clarity and spread. For example, I highly doubt we could get anywhere without considering what npm does.

I personally don't have too much time for this in the near future, since it will be quite some work fleshing out a complex spec like this, which will be much more complex than semver itself. However, I will gladly provide my feedback to any proposals and hereby declare my earlier draft to be placed in the Open Domain for anyone to take inspiration from (if I didn't do that already).

@FichteFoll commented on GitHub (Dec 9, 2017): I also mentioned this before, but let me state again that SemVer and a range selection syntax for semantic versions should be separate. Of course, the latter depends on the former, so it probably needs to be updated whenever the former is, but that's insignificant. This issue (and my draft) haven't seen any attention in recent time iirc, but imo this is still an area that could (or should, rather) be tackled and referenced on semver.org. It will not be the only standard for specifying semantic version ranges, but we should aim to be the *de facto* standard. Just like semver is not the only versioning scheme but a very popular one. Since it's been over three years since this issue (and the draft) have been worked on, we should take another look at the various selectors other tooling software has implemented and weight their options depending on usability, clarity and spread. For example, I highly doubt we could get anywhere without considering what npm does. I personally don't have too much time for this in the near future, since it will be quite some work fleshing out a complex spec like this, which will be much more complex than semver itself. However, I will gladly provide my feedback to any proposals and hereby declare my earlier draft to be placed in the Open Domain for anyone to take inspiration from (if I didn't do that already).

GiteaMirror commented

2026-06-20 16:52:24 -05:00

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

@FichteFoll & @jeffhandley, version selectors are like programming languages, we all have preferences, and most of those are standardized somewhere. There's no programming language standard for the same reasons there should never be a SemVer selector standard. Document whatever selector standards you see fit to solve whatever problems you need solutions for. I see no compelling reason to include any of them in the SemVer spec. If we go down that road, shouldn't SemVer define Dev-Ops platforms and programming languages for developers?

@jwdonahue commented on GitHub (Dec 12, 2017): @FichteFoll & @jeffhandley, version selectors are like programming languages, we all have preferences, and most of those are standardized somewhere. There's no programming language standard for the same reasons there should never be a SemVer selector standard. Document whatever selector standards you see fit to solve whatever problems you need solutions for. I see no compelling reason to include any of them in the SemVer spec. If we go down that road, shouldn't SemVer define Dev-Ops platforms and programming languages for developers?

GiteaMirror commented

2026-06-20 16:52:26 -05:00

@FichteFoll commented on GitHub (Dec 12, 2017):

I see no compelling reason to include any of them in the SemVer spec.

Again, this is not supposed to happen. It would be an entirely separate spec, potentially referenced and recommended by the semver website.

Most package managers use their own tooling and implementations of version selectors currently and I believe it would be beneficial to have a largely accepted standard that these implementations could refer to and that would reduce the cognitive load on developers who are switching between different ecosystems with different selector syntaxes.

As oppsed to programming languages, I don't believe you can do that much different with version selectors and it's a comparatively trivial task to reduce this down to a common set of operations (and syntax).

Edit: In fact, the selector syntax could be specified in such a way that it is compatible with more than just SemVer as its base. Python packages use a largely different syntax for example, but they use the same ASCII characters and have properly defined ordering.

@FichteFoll commented on GitHub (Dec 12, 2017): > I see no compelling reason to include any of them in the SemVer spec. Again, this is **not supposed to happen**. It would be an entirely separate spec, potentially referenced and recommended by the semver website. Most package managers use their own tooling and implementations of version selectors currently and I believe it would be beneficial to have a largely accepted standard that these implementations could refer to and that would reduce the cognitive load on developers who are switching between different ecosystems with different selector syntaxes. As oppsed to programming languages, I don't believe you can do that much different with version selectors and it's a comparatively trivial task to reduce this down to a common set of operations (and syntax). Edit: In fact, the selector syntax could be specified in such a way that it is compatible with more than just SemVer as its base. Python packages use a largely different syntax for example, but they use the same ASCII characters and have properly defined ordering.

GiteaMirror commented

2026-06-20 16:52:27 -05:00

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

So, when there are any foreign specs worth referencing, open an issue to add a link to it. The title of @jeffhandley's original post is "SemVer needs to define Version Range Spec syntax/behavior". I think this particular issue should be closed.

@jwdonahue commented on GitHub (Dec 13, 2017): So, when there are any foreign specs worth referencing, open an issue to add a link to it. The title of @jeffhandley's original post is "_SemVer needs to define Version Range Spec syntax/behavior_". I think this particular issue should be closed.

GiteaMirror commented

2026-06-20 16:52:28 -05:00

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

@jeffhandley, unless you have questions or intend to issue a pull-request, please close this thread at your earliest possible convenience.

@jwdonahue commented on GitHub (Oct 8, 2018): @jeffhandley, unless you have questions or intend to issue a pull-request, please close this thread at your earliest possible convenience.

GiteaMirror commented

2026-06-20 16:52:28 -05:00

@alexandrtovmach commented on GitHub (Jun 10, 2020):

This issue looks staled and will be closed in 10 days if there are no objections. Thanks everyone for contributions, you're amazing 🎆

@alexandrtovmach commented on GitHub (Jun 10, 2020): This issue looks staled and will be closed in 10 days if there are no objections. Thanks everyone for contributions, you're amazing :fireworks:

GiteaMirror commented

2026-06-20 16:52:29 -05:00

@alexandrtovmach commented on GitHub (Jun 19, 2020):

👻 👻 👻
Closed as staled

@alexandrtovmach commented on GitHub (Jun 19, 2020): 👻 👻 👻 Closed as staled

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#7111