mirror of
https://github.com/semver/semver.git
synced 2026-03-22 22:20:28 -05:00
How to behave if a project uses SemVer, but its maintainer is made to show the version of that project in SemVer incompatible format? #111
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#111
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 @dvorapa on GitHub (Nov 19, 2013).
We call for a little note in the FAQ under the specification clarifying, how to behave when any service requires the 4th (5th, 6th, ...) number from us. My proposal would look like this:
This issue formerly refferenced two problems. For the second problem where the dependency of the project requires to add its version after the project's one I created separate issue #243
Please share your opinion with us and think about it ;)
@allan-stewart commented on GitHub (Nov 20, 2013):
If a 4-part number isn't adopted formally into SemVer, you could use the
+metadata convention for it (build number or other data). E.g.: version1.3.0+453. Right?@dvorapa commented on GitHub (Nov 20, 2013):
Yes, I know, but when you want to submit a project into some popular sites (like any Google software addons or Microsoft software addons or more site like this if you are a developers of that kind of the software), there is a rule of four numbers and three dots. So what to write to the last digit if I strictly use Semantic Versioning? (better to ask straight)
@rlidwka commented on GitHub (Dec 13, 2013):
+1, very much would like to see it.
Build number don't fit here because it's ignored when determining version precedence.
@noirotm commented on GitHub (Dec 15, 2013):
-1 for several reasons:
A simple example is this:
1.0.5+gabc134f,1.0.5+g5e6b547, etc... These version numbers use Git commit hashes as metadata to identify the particular commit on which the release is based. Git hashes are definitly not sortable through lexical analysis. However, parsing the output of a Git log can allow to semantically retrieve the chronological order of the releases.A fourth number would just add confusion. Would it mean that nothing actually changed in the exposed functionality of the software, but it's actually different ?
Build metadata make it clear that the software is indeed different somehow, but the change is for example internal only, and either release with the same X.Y.Z numbers may be used without incompatibility issues.
So yes, there are notable developers and companies that use a four-numbered versioning scheme, but I believe that what Semver currently proposes is a better alternative.
@maximal commented on GitHub (Dec 15, 2013):
@noirotm takes the cake!
@JakeGinnivan commented on GitHub (Dec 15, 2013):
Are your internal dev builds Semantically Versioned?
If your CI builds are always the correct SemVer (after a release the patch is +1'd and you can also bump major/minor at any time), then you should use +buildmetadata
If your CI build is not a semantic version, then use the 4 part version number because it is NOT a semantic version?
@dvorapa commented on GitHub (Dec 16, 2013):
Stop that! As I wrote:
Our small developer team strictly use sematic versioning. My first ask was and is what to fill as the fourth number after the third dot when we want to post our app onto Google Play or Microsoft Store databases. In our Team, we decided to translate the semver to the required format by adding extra zeros.
For example our actual version is 3.2.0, but we have to translate it into 3.2.0.0, because Google Play has the four-digit and three-dot rule. Or do you have any other idea how to make our project submitted on the Google Play, but with the use of semver?
@cdbennett commented on GitHub (Dec 23, 2013):
@dvorapa It sounds like semantic versioning's pre-release versioning is exactly what you need for your development builds. Then, when you create the release build that you will upload to the public software center (e.g. Google Play), you build the release version with Semantic Version consisting of the major.minor.patch and upload with an added ".0" to satisfy the four-component rule of Google Play. You can just ignore the fourth component ".0" forever, it's just a placeholder.
For example, let's suppose your last release to the software store was 3.1.5 and you are working on version 3.2.0. Then you can use the pre-release feature of semver from point 9:
So you would be internally building
3.2.0-4,3.2.0-5,3.2.0-6or you could include an additional alphanumeric component to make it more explicit that it's a development version, like3.2.0-alpha.53.2.0-dev.5, etc. You also could eliminate the dot before the final number, but that means that ordering comparison would not be correct when the number of digits changed, e.g.3.2.0-dev.9<3.2.0-dev.10but3.2.0-dev10<3.2.0-dev9since mixed alpha+numeric are compared lexically, not numerically.Then after developing with
3.2.0-dev.5you are ready to release, so you build with semantic version3.2.0and upload to the software store adding a dummy.0to make3.2.0.0.@dvorapa commented on GitHub (Dec 25, 2013):
Yes, that's a good idea to write the last zero. It looks as the best semantic solution :)
@glebm commented on GitHub (Jan 7, 2014):
Here is a use case where we really do need the fourth number, as far as I can tell.
bootstrap-sass is an automatic conversion of bootstrap (written in Less) to Sass. Bootstrap uses semver, and bootstrap-sass maintains the same version number, but with the addition of the fourth number to specify Sass-specific version, in case we need to fix something specific to the Sass port, while keeping the same version of the framework. So for bootstrap 3.0.3, we would initially release
3.0.3.0(rubygems standard, originally the only package repository supported by bootstrap-sass). Later, if a bug were discovered in the Sass code, we'd fix it and release3.0.3.1, maintaining patch-level compatibility with bootstrap version.SemVer spec does not seem to account for this use case, causing discovery problems with various implementations such as npm or composer.json.
Since
3.0.3.0is not a valid SemVer version number, I initially had figured we had two options:3.0.3-0- turned out to be inadequate since the number after-is defined as pre-release.3.0.3+0- also inadequate, asAt the moment it appears SemVer does not provide a solution
The pragmatic programmer in me says the best answer would be to allow
3.0.3.0, as in Major -> Minor -> Patch -> Extra.@cdbennett commented on GitHub (Jan 7, 2014):
@glebm You have a good point. There's no really satisfactory solution in semver for that. There's a good comment explaining Debian version numbering and you could adopt some of the Debian conventions, which in particular allow a plus
+to still maintain precedence ordering. It might be useful for you to adopt semver but allow the "build metadata" aspect to deviate from the semver spec and apply ordering to it as well.@dvorapa commented on GitHub (Jan 7, 2014):
@glebm I thought, it could be also in the other cases the problem (the fourth number). The "Extra" should have strict rules, when and why to use it to make it unattractive in the usual cases, but in the special cases, it could help with ours problems like mine or yours.
Our problem is, that we declare, that we use the SemVer in the full words, but on some sites, where our API is uploaded for the users of our API, there is the idontwanttosaytheadjectiveimean fourth number rule and we have to explain all over again, that it is semantic versioned, but the service, how to get our product to our customers, has its own rules.
In my opinion, yours problem @glebm could be declared like + and - additions: It means with special sign (× or ÷ or ~ or something like it) and it could be declared as the case, which completely corresponds with yours case. So the version of your application should look like X.Y.Z~x.y.z (uppercase is the major application and lowercase is your addition under the major application).
Your case could be discussable more than mine. I have to explain more and more, that im strictly using the SemVer, but the service don't allow me that, so I have to use the last zero... But yours case is really important and should be pullrequested.
Update: see #243 for more
@dvorapa commented on GitHub (Jan 7, 2014):
I'm AGAINST the Major.Minor.Patch.Extra. Is there any other idea? Share, write, discuss, because in these days it looks like two important problems!
@rlidwka commented on GitHub (Jan 8, 2014):
It's called "Major.Minor.Micro.Patch" usually
@leif81 commented on GitHub (Jan 10, 2014):
@glebm The Fedora Project has a similar requirement. It takes an upstream projects source tar.gz's and packages them into an rpm's. The packaging process is non trivial so it too requires a version field. They call this extra field a release tag.
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Release_Tag
e.g. %{name}-%{version}-%{release}
mozilla-1.4-1" followed by "mozilla-1.4-2" etc.
@andrerom commented on GitHub (Jan 15, 2014):
If this is ever added somehow, this should also be allowed for production release.
Use case: Specifying that only this nano version number can change in production.
So only allow use of this number for Critical issues, example: Release Blockers (pre release) and security fixes (post release).
Or is there something else that can be used to specify that only security patches are allowed with SemVer? Build number meta information specifically mentions there is no ordering so seems unsuitable.
@rlidwka commented on GitHub (Jan 15, 2014):
There was a practice somewhere to name security versions as 4th numbers.
For example, you have a schedule. You release v1.2.3 with fix X, then after a while you plan to release v1.2.4 with fix Y, and so on.
But security bug is discovered, so you have to put a new version between current v1.2.3 and scheduled to release v1.2.4. So people sometimes name it v1.2.3.1 with a 4th number being a security release.
@leif81 commented on GitHub (Jan 15, 2014):
It's my opinion that if a critical issue arises (security or otherwise) that you just cut a bug fix release right away.
I don't see the need to add more complexity to your process with a 4th digit. Every decimal place added to a project version adds a requirement for more QA resources (to test these special builds), more branch maintenance (cherry picking, merging, back porting, etc), more engineering infrastructure (new job builders), more artifacts to archive and distribute, etc.
I say to heck with it. A security fix is just another bug and should be treated by incrementing the third digit which is already reserved for this exact purpose.
@rlidwka commented on GitHub (Jan 15, 2014):
How to emphasize that it is a security release? So people will look at it and think that they need to install it ASAP even if they didn't get patch notes?
@dvorapa commented on GitHub (Jan 15, 2014):
Well, it actually is, I only rewrote and commented, what @glebm had proposed.
Okay, I'm AGAINST Major.Minor.Micro.Patch pattern.
My very realistic opinion is, that SemVer v2.0.0 is still really early preview of the spec with the main things relatively declared, but stil with so many bugs and issues requiring for its fix metadata additions. Well, just discuss ;)
@andrerom commented on GitHub (Jan 15, 2014):
This is possible, but it does not solve the build issue and, well, it is not really the same. Normal everyday bugs are not the same as very small but extremely critical fixes, which is either:
Both which should be relatively easy to review and push to production.
In fact, such a fix should be so unintrusive you should be able to allow it to be automatically applied similarly to how you can configure some linux distributions to apply security fixes automatically.
But let me repeat that I'm (and others in this thread) agnostic regarding if this is solved as a fourth number or some other means like semantic sorted meta info widely used already in the software world, and which is maybe more suitable for the build use case.
@noirotm commented on GitHub (Jan 16, 2014):
Use build metadata, for instance like this:
This even gives a nice reference to the fixed vulnerability.
@andrerom commented on GitHub (Jan 16, 2014):
Doesn't solve the use case to allow only security updates of a third party package.
For instance if there is 1.2 LTS branch and latest one is 1.2.3, then "~1.2.3" means >= 1.2.3 && < 1.3.0, but there is no way to specify production requirement like "1.2.3+" which would mean >= 1.2.3 && < 1.2.4. Also build meta data is ignored by package managers like composer because it is documented as "Build metadata SHOULD be ignored when determining version precedence", so you can probably not push out to builds with same version and different build meta data (But @Seldaek might want to [un]confirm that). And even if you can, sorting is then not following any info in the version number but rather timestamp of the tag/build, which is outside of the control of the SemVer convention.
No matter how you look at it SemVer is missing functionality to redo a version with other build number / security fixes in a way that is actually supported, sorted and understood by the standard and it't implementation. A workaround would be to create a convention for build meta data that package managers adopt.
@Seldaek commented on GitHub (Jan 16, 2014):
@andrerom within the context of Composer version constraints (which I assume most people don't care much about here),
~1.2.3indeed means>= 1.2.3 && < 1.3.0, if you want any sub-patch release (call them security releases or build number) you can require~1.2.3.0which would mean>= 1.2.3.0 && < 1.2.4, Composer internally translates 1.2.3 into 1.2.3.0 anyway, because yes a fourth level is sometimes useful in the wild.That said, I don't think your security releases should be tagged 1.2.3.1. I think it should be 1.2.4. If you do it this way you fit into semver and it's just as correct, security fixes are bug fixes. I don't see why everyone is so afraid of increasing numbers in a version string.
@andrerom commented on GitHub (Jan 16, 2014):
Because bug fixes sometimes break stuff, plain risk management..
But if your saying composer already supports this internally then I got my build and potential security micro releases needs covered, and can move on :)
@leif81 commented on GitHub (Jan 31, 2014):
MediaWiki is an example of a project that double-hats the third field (aka Patch field, Z field) for both bug fixes and security fixes. e.g.
MediaWiki 1.21.2 is a security fix release, http://lists.wikimedia.org/pipermail/mediawiki-announce/2013-September/000133.html
MediaWiki 1.21.1 is a bug fix release, http://lists.wikimedia.org/pipermail/mediawiki-l/2013-May/041285.html
@leif81 commented on GitHub (Jan 31, 2014):
To follow up on that last MediaWiki example, this page quite clearly shows how they mix and match bug and security fixes into the third field.
https://www.mediawiki.org/wiki/Release_notes/1.21
@milesrout commented on GitHub (May 6, 2014):
A security fix is a bug fix and should go in the 3rd column.
@JamesMGreene commented on GitHub (Jan 21, 2015):
👍 for this issue, it is especially bothersome for downstream wrappers (e.g. bootstrap-sass, the Node.js module wrapper for PhantomJS, the Node.js wrapper for Adobe/Apache Flex SDK, etc.).
My big fear is that we'll add the 4th place (which I am mostly in favor of) but then that would become standard for upstream libraries, and subsequent the downstream wrappers would need a 5th number, etc.
In light of that fear, I've proposed something a little different in my newly filed Issue #242: infinite (
n) optional numeric version segments trailing after the "core" version (MAJOR.MINOR.PATCHtrio).@dvorapa commented on GitHub (Jan 21, 2015):
Yes, the issue is still open, but I don't agree with your proposal. We shouldn't change the main core of semver specification, because it is really sophisticated. In my opinion we should just call for a little note or small paragraph at the end of the specification (or in the FAQ under the specification) clarifying, how to behave when any service requires the 4th (5th, 6th, ...) number from us. My proposal would look like this:
@glebm commented on GitHub (Jan 22, 2015):
Bootstrap Sass had to switch to 3-digit numbers to be compatible with npm and bower. It no longer has MAJOR.MINOR.PATCH parity with upstream. :'(
@dvorapa commented on GitHub (Jan 22, 2015):
Sounds great! Or not? Bootstrap goes SemVer!
@dvorapa commented on GitHub (Jan 22, 2015):
BTW see the updated description and #243 derived from this issue
@EddieGarmon commented on GitHub (Jan 22, 2015):
Your dependencies' versions should not be directly embeddable in your version number, even if you are nothing but a wrapper API.
From: Pavel Dvořákmailto:notifications@github.com
Sent: 1/21/2015 7:26 PM
To: mojombo/semvermailto:semver@noreply.github.com
Subject: Re: [semver] What to do if any package/app management service requires the 4th number to be filled in? (#168)
Sounds great! Or not? Bootstrap goes SemVer!
Reply to this email directly or view it on GitHub:
https://github.com/mojombo/semver/issues/168#issuecomment-70949903
@glebm commented on GitHub (Jan 22, 2015):
@dvorapa It's not great, confused users ensue. 🔥
@dvorapa commented on GitHub (Jan 22, 2015):
@EddieGarmon Yes, they should not. But if Bootstrap begins using SemVer, it should from now add sass number after + letter right? Therefore I think there is no confuse! @glebm Or please explain me better if I missed something. (maybe missed, because I can't speak english very well)
@glebm commented on GitHub (Jan 22, 2015):
@dvorapa Bootstrap (written in LESS) has always been semver. The Sass conversion of bootstrap, a separate package called bootstrap-sass, tried hijacking the plus
+for these post-release versions, but had to drop it because of incompatibilites with bower and npm. Now, if we need a post-release for bootstrap-sass, we increment the PATCH in bootstrap-sass, and then skip that PATCH in bootstrap. The latest bootstrap-sass is 3.3.3, but that corresponds to bootstrap 3.3.2. The next version of bootstrap will be 3.3.4+ and there will be no bootstrap 3.3.3, because that PATCH was used by bootstrap-sass. 😕@JamesMGreene commented on GitHub (Jan 22, 2015):
I'm with ya, @glebm. It's a crappy situation but, honestly, even after spending pretty much all day thinking through this and prototyping some alternative schemes (see #242), I've arrived at the conclusion that this just isn't really possible because we're trying to represent 2 semi-independent version numbers simultaneously. 👎 😩
@glebm commented on GitHub (Jan 22, 2015):
@JamesMGreene It only "works" for us because the same team maintains bootstrap and bootstrap-sass.
@dvorapa commented on GitHub (Jan 22, 2015):
@glebm Just a little bit. @JamesMGreene That's it. There are at least three usages of the 4th number if I remember. All were discussed in this thread. So there are 3 semi-independent version numbers simultaneously represented by one
EXTRApattern. Therefore I've tried to replace one of the usecases of the 4th number by tilde pattern (see #243). You could help to clarify its usage, I think I didn't expressed its purpose in the right way. And there could be proposed more than just~(like x # / * .. and so on). And I'm also trying to propose addition to SemVer's FAQ to replace the second usecase. Let's open the dicussion again!@milesrout commented on GitHub (Jan 22, 2015):
@dvorapa You don't need an EXTRA number.
Next!
@dvorapa commented on GitHub (Jan 23, 2015):
@milesrout No, you sometimes need an extra number, please read the description of this issue at the beginning!
@FichteFoll commented on GitHub (Jan 23, 2015):
The problem in OP has been solved and the solution is even listed there: Just add
.0indefinitely. There is no need to add that to the spec because everything else than three main numbers is a different versioning scheme and semver can't claim to be compatible with them all, nor provide steps to achieve compatability.The other issue raised in this discussion is discussed more deliberately in #243, #17 and most recently #242. Similar: #80, #148.
@dvorapa commented on GitHub (Jan 23, 2015):
There is big caveat, that it isn't anywhere in the spec, how to behave, if anybody requires on us anything out of spec. It is needed to be clarified somewhere in the FAQ, because too many questions about these problems are asked on stackoverflow and nobody is interested in adding one more question under FAQ of the semver about how to behave if --the title of this bug--.
@milesrout commented on GitHub (Jan 25, 2015):
It isn't related to the spec and it has nothing to do with the spec. How you wrangle semver into the hundreds of different versioning schemes out there has nothing to do with semver. You want support for four-numbered schemes in semver. Do you also want support for odd-unstable-even-stable schemes, like the pre-3.x Linux scheme? Do you want support for schemes that converge to an irrational number with each new version, like TeX?
semver's spec is about semver. Can we please leave it that way?
@milesrout commented on GitHub (Jan 25, 2015):
And how is it not completely obvious that you do whatever you want with the fourth number?
@dvorapa commented on GitHub (Jan 25, 2015):
@leif81 commented on GitHub (Jan 26, 2015):
@dvorapa I think zero padding the extra digits as you had suggested is the best and only solution for using a semver in a non-semver environment.
FWIW...I'd lean against semver documenting this case though. People may interpret it as support for four digits which as this discussion shows is like opening a can of worms!
Just zero the extra digits and move on :)
@JamesMGreene commented on GitHub (Jan 26, 2015):
@dvorapa: Seems reasonable and appropriate to add such a note to the FAQ section but definitely NOT to the main spec sections. 👍
@dvorapa commented on GitHub (Jan 26, 2015):
@leif81 it is worse, like throwing an openned can of TNT into a fire ;-)
@JamesMGreene I've removed proposed paragraph in the description of this issue. It definitely should be in FAQ, you're right.
@jedwards1211 commented on GitHub (Mar 23, 2017):
@glebm that makes sense in your case, but I think it's too specific to become a widely adopted interpretation of a 4th version number.
It may seem like a 4th version number is applicable for all packages whose version tracks the version of an upstream project, but its use is really much more limited. Imagine a webpack plugin for example; say you want the versions of your plugin to match the versions of webpack. But what if you want to add a completely new feature to your plugin -- which version number do you increment then? Or if you make a breaking change in your plugin while still targeting compatibility with the same webpack version? I think it only makes sense to track another package's version number in cases like yours where your package content is almost entirely determined by the content of the other package, and you know there are going to be no major changes in how you build/convert from the other project. So the 4th version number would have pretty limited relevance.
@jwdonahue commented on GitHub (Dec 3, 2017):
@dvorapa, unless you intend to pursue this issue further, you can please close it at your earliest possible convenience?
It's my opinion that SemVer shouldn't prescribe policy for conversions between itself and other versioning conventions. There's just too many variables to account for.
@dvorapa commented on GitHub (Jan 12, 2018):
I just asked how to continue with this problem. Yes, becuase there is too many variables to account for and SemVer in my opinion should give some possible solution. Not concretely, at least inconcretely
@jwdonahue commented on GitHub (Jan 12, 2018):
@dvorapa, let's work this one. I've been working the SemVer tag on StackOverflow lately and there are some questions there and here regarding mappings between schemes. It seems a FAQ would be useful, but I don't think we can provide a simple formula.
How you map the SemVer triple to any foreign versioning scheme is highly dependent on the semantics of the foreign scheme and your own product release policies. When you enter a version number into a packaging ecosystem, you are committing to whatever contracts are implied by the use of that scheme. Consider the reverse problem of mapping from the foreign scheme onto SemVer. Are there any elements in the foreign scheme that imply any of the semantics of SemVer's version fields? Generally there are none, therefore the entire foreign version number must be shifted right and SemVer's two most significant fields should be zeroed.
Foreign version, semantics unknown: 1.3.7.1248
SemVer: 0.0.1-3.7.1248 or 0.0.0-1.3.7.1248
It is possible that the foreign scheme has some kind of semantic meaning, but the implied contract is usually so weak that none of them map onto any SemVer number above the 0.0.x range. So generally, given that SemVer is stronger than most foreign schemes, you have a good bit of freedom, but you should always consider how package dependencies are resolved in the target ecosystem and think through the implications of that, for your own release cycles. If you shift the semver number to the left in the foreign scheme, will your bug fixes be picked up? Maybe you can't just shift them, maybe in order to maximize for your needs, you maintain a completely different version number using the proper semantics of the foreign scheme. It might be that SemVer's major or minor numbers have some significance in specific fields in the foreign scheme, but the rest of the string just doesn't have any mapping at all.
I don't think we can say "just zero the least significant field". One possible scenario is that you designate the foreign scheme's most significant field to your marketing department and map the SemVer version number into the middle or right most fields of the foreign scheme. Or maybe, your SemVer number winds up in the title or description of the foreign system. Some development processes always include a build meta tag that incorporates a sequential build number, you might want to move that into the the build number field of the foreign scheme.
Can we condense all of that into one or two paragraphs in a FAQ?
@jwdonahue commented on GitHub (Jul 15, 2018):
@dvorapa, unless you require further clarification, please close this issue at your earliest possible convenience. Thank you.
@dvorapa commented on GitHub (Jul 15, 2018):
There still should be some paragraph in the FAQ
@jwdonahue commented on GitHub (Jul 15, 2018):
@dvorapa
What could the FAQ possibly say? Always using zero is wrong and so is always using any other number. The right thing to do, depends heavily on how the automation and humans interpret the fields and the changes you've made to your product. There is nothing the FAQ could say that would be generally correct. Your solution to the problem may work for you, but it's not going to work for everybody.
Why doesn't this competing scheme document the mapping to/from other schemes? Maybe they should at least provide a mapping to SemVer? Why place the burden on the SemVer spec and FAQ? If it's on SemVer, then which competing schemes should be covered? Google Play and Microsoft Store use versioning schemes that solve a different problem than SemVer, NPM and Nuget coverage makes more sense, but they both support SemVer anyway, as well as their own four digit schemes (or they used to), so where's the fire?
Unless you intend to issue a PR with suggested language for this entry in the FAQ, I don't know who would want to make the attempt. My knowledge of the problem space, suggests it would require an entire white paper on the subject of mappings between version schemes and it has to take a range of development practices into account as well. My gut tells me that persons of average intelligence, don't need us to tell them how to solve this problem, and would probably recognize the fallaciousness of any trivial advise we might give. Unfortunately, there's too many developers out there, who wouldn't be that smart, they'd blindly follow the simple advice given and then complain when they cause millions of dollars of damages due to their ignorance.
Coming from an electronics hobbyist background, I think of this as an interface impedance issue. Even in electronics, where their's formulas that can be applied to get you into the general vicinity of where you want to be, it's still a bit of a black art, as there's always trade-offs to be made in terms quality, power, cost, etc. For software interfaces and version schemes, we don't even have a theory to guide us through the problem space.
What should you do if a tool doesn't meet your needs? Adapt to the tool or find another one.
Unless you intend to issue a PR for this issue, please close it. I'am trying to keep the list of open issues within the realm of what might actually get done before the end of this century, and I don't think this issue is going to lead to any changes.
@jedwards1211 commented on GitHub (Jul 16, 2018):
@dvorapa how about "if you need to release software in a store that doesn't accept SemVer version numbers in its versioning scheme, please use your own judgement about what version numbers to use for that store"
@jwdonahue commented on GitHub (Oct 8, 2018):
@dvorapa, unless you intend to issue a PR, please close this issue at your earliest possible convenience.
@jwdonahue commented on GitHub (Jan 17, 2020):
@dvorapa, there's been no motion on this for months. Please close at your earliest possible convenience.
@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 contribution, you're amazing 🎆
@alexandrtovmach commented on GitHub (Jun 19, 2020):
👻 👻 👻
Closed as staled