Semver dependency?
See original GitHub issueWith paket pack
and paket.template
, and using ~> #{version}
, https://www.nuget.org/packages/Suave/2.3.0-beta depends on wrong versions; too constrained. I’d like to do a semver dependency. Is there a squiggly for that? (Besides (3, 4.0]
)?
Issue Analytics
- State:
- Created 6 years ago
- Reactions:1
- Comments:7 (7 by maintainers)
Top Results From Across the Web
Semantic Versioning 2.0.0 | Semantic Versioning
In the world of software management there exists a dreaded place called “dependency hell.” The bigger your system grows and the more packages...
Read more >semver
The semantic version parser used by npm.. Latest version: 7.5.4, last published: a month ago. Start using semver in your project by running ......
Read more >Semver: A Primer - NodeSource
Semver is important in Node.js because it's built into the way that npm manages package dependencies. What's more, semver ranges are almost ...
Read more >Semantic versioning on a dev dependencies change
Based on the Semantic Versioning specification, any changes to a versioned package must result in the release of a new version of the ......
Read more >Versions of dependencies
Packages in Yarn follow Semantic Versioning, also known as “semver”. When you install a new package from the registry it will be added...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
As far as I know at the moment you can achieve what you want’ by explicitly defining the range. For example:
nuget DotLiquid >= 2.0.174 < 3.0
will result dependency x >= 2.0.174 && x < 3.0So what you are asking for is a shortcut/syntax for creating dependencies from a given version to the next major? Something similar to the current “twiddle-waka” which will yield a “Pessimistic version constraint”, but so that it’ll always cap the upper boundary to the next major, even if minimum would be a patch version.
So for example a new operator
~>>
(“twiddle-waka-waka” is that then 😉) that would do just that. Broken into examples below (I’ll show the difference to related “twiddle-waka” results also):I really like the “twiddle-waka”, but I have found myself longing for this other shortcut as well. As most of the times what I actually want is exactly what described here (I want to have at least a specific patch and am happy to upgrade to anything up to the next major as the given nuget mainter has promised to follow SemVer).
Yes; @Gonnagle that’s a good idea, but I think this issue already requests that operator, don’t you?