mirror of
https://github.com/semver/semver.git
synced 2026-07-10 19:50:47 -05:00
[GH-ISSUE #56] version constraints #5162
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#5162
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 @GordonSchmidt on GitHub (Dec 6, 2012).
Original GitHub issue: https://github.com/semver/semver/issues/56
It would be nice to provide a standard handling the syntax of version constraints as well, because now this is handled differently in every tool. So it's hard to define the dependencies of your application, when your not familiar with the syntax the used dependency manager supports.
The standard would have to deal with comparison operators, wild-cards and/or stripped versions (support 1.2.* and/or 1.2), multiple constraints (how to list several constraints - just coma separated or support logical operators like AND and OR) and stability (how to include/exclude pre-release or only alpha versions).
Is this the right place for a discussion about this matter?
@haacked commented on GitHub (Dec 6, 2012):
Hi Gordon. Do you mean a standard implementation? Or something different?
@GordonSchmidt commented on GitHub (Dec 6, 2012):
I want to work out a specification for version constraints. So tools like dependency manager can implement this specification rather than coming up with there own syntax. The benefit of a shared syntax of version constraints would be huge. Users would not need to relearn the syntax, if they change tools. Converting package descriptions from on format to another would be much easier, if at least the version constraints don't have to be converted.
The differences between the syntaxes of existing tools might be not that huge, but there are differences. And clear specification might help to unify.
@haacked commented on GitHub (Dec 6, 2012):
Ah, I see. Yes, that's out of scope for SemVer.
I'm particularly fond of the maven version range specification:
This was the inspiration for NuGet's version constraints.
@GordonSchmidt commented on GitHub (Dec 6, 2012):
I use composer alot http://getcomposer.org/doc/01-basic-usage.md#package-versions
@Tieske commented on GitHub (Dec 6, 2012):
Is it really out of scope? then it is a close call at least.
I like the idea. it would also help to sort out dealing with the prelease versions (which pops up over and over again, just now; https://github.com/mojombo/semver/issues/57 )
It could for example resolve the issues of compatibility between pre-release versions (as in my request https://github.com/mojombo/semver/pull/30 which has unfortunatley seen no comments) by excluding pre-release versions from greater-than or less-than comparisons for example.
@haacked commented on GitHub (Dec 20, 2012):
@Tieske I still think it's out of scope. SemVer really defines what to put in the "version" number for a piece of software.
Semver answers the question, does this version fit the SemVer specs? What does each part mean?
1.0.0-alphaI definitely think a companion spec for version constraints could be useful. Maybe a SemVer constraint companion spec or some thing.
@Tieske commented on GitHub (Dec 20, 2012):
@GordonSchmidt did you find a right place for a discussion on this matter? Do you have a proposal?