mirror of
https://github.com/semver/semver.git
synced 2026-07-10 19:50:47 -05:00
[GH-ISSUE #344] Specification of normalizing non-semver to semver #7225
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#7225
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 @oneumyvakin on GitHub (Nov 23, 2016).
Original GitHub issue: https://github.com/semver/semver/issues/344
There are lot of software that doesn't use semver like OpenSSL or proftpd.
The main problem is for OpenSSL 1.1.0 is less that 1.1.0a. And 1.1.0a is less than 1.1.0b etc.
There is need are formal rules how to normalize not semantic version to semantic version which can be used by semver library developers.
@zafarkhaja commented on GitHub (Nov 23, 2016):
I think such rules should be specified by the vendors themselves, in case they believe their versions have any sort of compatibility with SemVer, if at all.
@oneumyvakin commented on GitHub (Nov 23, 2016):
It's not a question about what software vendor should do.
It's a question how software libraries(like https://github.com/Masterminds/semver) which implements SemVer should implement non-semver version normalization/conversion.
Currently some libraries specify some kind of it's own normalization, some libraries are not.
The problem here that is SemVer live inside it's own world and doesn't covers how other version should be represented in SemVer.
@FichteFoll commented on GitHub (Dec 1, 2016):
Technically, no version number that is not already a semver number can be converted to one, because, as the name implies, semver numbers include semantic meaning and as we know, semantics cannot be interpreted correctly by software. As such, converting a non-semver number to a semver number must be done by a human than can interpret semantics correctly – everything else would be a hack. And I doubt documenting hacks would be a good practice.
@oneumyvakin commented on GitHub (Dec 1, 2016):
@FichteFoll You are wrong because this "hacks" already implemented in libraries, like github.com/hashicorp/go-version - performs normalization but https://github.com/Masterminds/semver is not. (And I've take just two random libs for one lang).
And I can't fix this libs because they both are "correct", so lack of specification already leading to hacks.
For lib user it means that:
For semver ecosystem it means poor adoption, because legacy soft haven't migration path to semver.
@oneumyvakin commented on GitHub (Dec 4, 2016):
So this issue about "hacks" unification.
@stevek commented on GitHub (Dec 7, 2016):
It would be a great if the specification provided some guidance about storing and tracking semantic versioning numbers at the source level. As in prior comments, there are several utilities that do this via establishing a
.semverfile as YAML, but each one seems to use a slightly different format, making the portability of the information between tools a huge pain. Would adding a section on portably exposing the version information be out of scope for this spec?@FranklinYu commented on GitHub (Feb 17, 2017):
At least in the case of OpenSSL, its version can be safely converted to semantic versioning, because its version actually provides similar semantics. As far as I understand, OpenSSL 1.(x).(y) are like SemVer (x+1).(y).0; OpenSSL 1.(x).(y)a (to denote something like 1.0.2a) are like SemVer (x+1).(y).1; OpenSSL 1.(x).(y)b are like SemVer (x+1).y.2. This way OpenSSL version corresponds to semantic versioning properly, for example 1.1.0d can be translated to 2.0.4. I think I can even write a short code for that.
This is only for OpenSSL. Not every versioning system keeps the semantics (for example there is no breaking change in Ruby 2.0.0, so it's Ruby 1.10 in my mind).
@jwdonahue commented on GitHub (Nov 29, 2017):
@oneumyvakin
Can you give us some clue what this might look like in the SemVer spec? I don't believe it can be done reliably without an in-depth knowledge of the process that generates these non-SemVer version strings and some commitment on the part of the other parties to actually adhere to those processes.
I think the SemVer spec already gives you all the formal rules you need to have. If their rule is bump field N whenever a new feature is added, then you can map N to SemVer's minor field. Breaking changes map to major. Mapping alpha-numeric to numeric fields is a simple base conversion problem. Whatever "normalizing" scheme you come up with, it simply can't be valid if it causes a violation of the semantic versioning rules.
Unless you have additional ideas on how we might properly describe this normalization process without weakening the SemVer contract, please close this issue.
@probonopd commented on GitHub (Feb 25, 2018):
Relevant discussion in https://github.com/openssl/openssl/issues/5042
@jwdonahue commented on GitHub (Feb 26, 2018):
Some time in the next few weeks, I'll be publishing some rough proposals for what I believe are the next evolutionary steps required for semantic versioning. Primary among those are a standard version meta tag to reference a standardized version schema, that would be machine and human readable. I've already hinted at this in some responses on other threads in this project. I don't think the mapping between version schemes X and Y is nearly as interesting as how do we describe the semantics of each one? How can a machine assess the relevant risks when deciding which versions to take as an update? Or to put it another way, how can we define local policies in a general way, that can then be used to find appropriate versions?
@alexandrtovmach commented on GitHub (Jun 10, 2020):
Thanks everyone for contributions, you're amazing 🎆 Did you find any consensus?
@alexandrtovmach commented on GitHub (Jun 14, 2021):
Closing as staled, feel free to re-open or create a new issue 👻