Comments (15)
how would this look like?
@ilkerde @agross
from paket.
In bundler you would need to specify a version constraint including the prerelease suffix. I think this is useful, makes "we want prereleases" explicit.
Another option might be to add a boolean parameter to the nuget, such that you don't have to know the prefix used by the package authors. But this would make it hard to say "only rc prereleases, not alphas". I favor the first solution.
Alex
Alexander Groß
Tiny phone, tiny mail
On Tue, Sep 9, 2014 at 5:21 PM, Steffen Forkmann [email protected]
wrote:
how would this look like?
@ilkerde @agross
Reply to this email directly or view it on GitHub:
#26 (comment)
from paket.
so how would this look like?
2014-09-09 18:58 GMT+02:00 Alexander Groß [email protected]:
In bundler you would need to specify a version constraint including the
prerelease suffix. I think this is useful, makes "we want prereleases"
explicit.Another option might be to add a boolean parameter to the nuget, such that
you don't have to know the prefix used by the package authors. But this
would make it hard to say "only rc prereleases, not alphas". I favor the
first solution.Alex
Alexander Groß
Tiny phone, tiny mailOn Tue, Sep 9, 2014 at 5:21 PM, Steffen Forkmann [email protected]
wrote:
how would this look like?
@ilkerde @agross
Reply to this email directly or view it on GitHub:
#26 (comment)—
Reply to this email directly or view it on GitHub
#26 (comment).
from paket.
Prereleases are a somewhat difficult story. I saw different syles and conventions for prerel package versions. Every project seem to have its own flavor. For public projects, there seems to be an wider agreement on "rc" prerels, though.
AFAIK bundler would do this by just recognizing alphabetic characters, match them against the version in descending lexicographical order:
nuget "NUnit.Runners" "~> 2.6.9.beta"
This would simply match all beta prerels and get the "latest" (first of above described order).
I can add another alternative on the topic, just to have an open table for discussion.
In the majority of prerel scenarios, the consumer just wants to subscribe to latest. It's like a "yeah, I know bleeding edge is painful, but that's my game" thing. From that pov, one could argue to introduce such a descriptor on any part of SemVer, including prerel. Since we already do optimistic updates, we only would need such a subscription on prerel level. Hence, we could just prepend the descriptor to the version constraint.
Let's assume our descriptor for LATEST would be ^
(just figurative). We could subscribe to latest then like this:
nuget "NUnit.Runners" "~^> 2.6"
nuget "Paket" "~^> 0"
To have it a little more readable, we could play with the representation of the descriptor, something like
nuget "NUnit.Runners" "~>> 2.6"
to denote that we opt-in for prereleases, no matter how it was specified (dev, alpha, dog, beta, rc). Let's say we only opt-in for rc
prerels, then we could do something like
nuget "NUnit.Runners" "~>> 2.6.9.rc"
One interesting thing to consider is how pessimistic updates would work with prerels. Let's assume a constraint like:
nuget "Paket" "!~>> 0.0.4"
I guess I'd expect here to stay on lowest of 0.0.4
no matter if prerel or not. Just my 2c. @agross ?
from paket.
Good points, I like the new notation.
The ! operator does only influence resolution of the package's dependencies, not the resolution of the package itself. It would work with the bleeding edge specifier just fine in that it takes the oldest matching deps of Paket in your case.
Alex
Alexander Groß
Tiny phone, tiny mail
On Tue, Sep 9, 2014 at 8:18 PM, ilkerde [email protected] wrote:
Prereleases are a somewhat difficult story. I saw different syles and conventions for prerel package versions. Every project seem to have its own flavor. For public projects, there seems to be an wider agreement on "rc" prerels, though.
AFAIK bundler would do this by just recognizing alphabetic characters, match them against the version in descending lexicographical order:
nuget "NUnit.Runners" "> 2.6.9.beta"^> 2.6"
This would simply match all beta prerels and get the "latest" (first of above described order).
I can add another alternative on the topic, just to have an open table for discussion.
In the majority of prerel scenarios, the consumer just wants to subscribe to latest. It's like a "yeah, I know bleeding edge is painful, but that's my game" thing. From that pov, one could argue to introduce such a descriptor on any part of SemVer, including prerel. Since we already do optimistic updates, we only would need such a subscription on prerel level. Hence, we could just prepend the descriptor to the version constraint.
Let's assume our descriptor for LATEST would be^
(just figurative). We could subscribe to latest then like this:
nuget "NUnit.Runners" "
nuget "Paket" "^> 0">> 2.6"
To have it a little more readable, we could play with the representation of the descriptor, something like
nuget "NUnit.Runners" "
to denote that we opt-in for prereleases, no matter how it was specified (dev, alpha, dog, beta, rc). Let's say we only opt-in forrc
prerels, then we could do something like
nuget "NUnit.Runners" ">> 2.6.9.rc">> 0.0.4"
One interesting thing to consider is how pessimistic updates would work with prerels. Let's assume a constraint like:
nuget "Paket" "!I guess I'd expect here to stay on lowest of
0.0.4
no matter if prerel or not. Just my 2c. @agross ?Reply to this email directly or view it on GitHub:
#26 (comment)
from paket.
Instead of messing with the already very complicated operators I suggest suffixes:
nuget FAKE => 0 prerelease // just give me latest
nuget FAKE ~> 2.2 rc // 2.2 < x < 3 including rc
nuget FAKE >= 3 beta // at least 3.0 including rc and beta
Alpha suffix would behave like prerelease
from paket.
I've seen packages (Nservicebus) using "Unstable" suffixes. How would this work with thr rc, beta, alpha keywords you suggest?
Wouldn't it be better not to hard-code the types of prereleases we support?
from paket.
mhm. unstable would be found by prerelease
maybe we should not hardcode and improve to:
nuget FAKE => 0 prerelease // just give me latest (prerelease is special)
nuget FAKE ~> 2.2 rc // 2.2 < x < 3 including rc
nuget FAKE >= 3 beta // at least 3.0 including beta
nuget FAKE > 1 alpha // greater 1.0 including alpha
nuget FAKE > 1 beta rc unstable // greater 1.0 including alpha, beta, unstable
from paket.
So any alphabetical token would be allowed?
Alex
Alexander Groß
Tiny phone, tiny mail
On Wed, Sep 24, 2014 at 6:17 PM, Steffen Forkmann
[email protected] wrote:
mhm. unstable would be found by prerelease
maybe we should not hardcode and improve to:
nuget FAKE => 0 prerelease // just give me latest (prerelease is special)
nuget FAKE ~> 2.2 rc // 2.2 < x < 3 including rc
nuget FAKE >= 3 beta // at least 3.0 including beta
nuget FAKE > 1 alpha // greater 1.0 including alphanuget FAKE > 1 beta rc unstable // greater 1.0 including alpha, beta, unstable
Reply to this email directly or view it on GitHub:
#26 (comment)
from paket.
Yep
On Sep 24, 2014 6:51 PM, "Alexander Groß" [email protected] wrote:
So any alphabetical token would be allowed?
Alex
Alexander Groß
Tiny phone, tiny mailOn Wed, Sep 24, 2014 at 6:17 PM, Steffen Forkmann
[email protected] wrote:mhm. unstable would be found by prerelease
maybe we should not hardcode and improve to:
nuget FAKE => 0 prerelease // just give me latest (prerelease is
special)
nuget FAKE ~> 2.2 rc // 2.2 < x < 3 including rc
nuget FAKE >= 3 beta // at least 3.0 including beta
nuget FAKE > 1 alpha // greater 1.0 including alpha
nuget FAKE > 1 beta rc unstable // greater 1.0 including alpha, beta,unstable
Reply to this email directly or view it on GitHub:
#26 (comment)—
Reply to this email directly or view it on GitHub
#26 (comment).
from paket.
Sounds good! And we may choose from several tokens, right?
Alex
Alexander Groß
Tiny phone, tiny mail
On Wed, Sep 24, 2014 at 6:57 PM, Steffen Forkmann
[email protected] wrote:
Yep
On Sep 24, 2014 6:51 PM, "Alexander Groß" [email protected] wrote:So any alphabetical token would be allowed?
Alex
Alexander Groß
Tiny phone, tiny mailOn Wed, Sep 24, 2014 at 6:17 PM, Steffen Forkmann
[email protected] wrote:mhm. unstable would be found by prerelease
maybe we should not hardcode and improve to:
nuget FAKE => 0 prerelease // just give me latest (prerelease is
special)
nuget FAKE ~> 2.2 rc // 2.2 < x < 3 including rc
nuget FAKE >= 3 beta // at least 3.0 including beta
nuget FAKE > 1 alpha // greater 1.0 including alpha
nuget FAKE > 1 beta rc unstable // greater 1.0 including alpha, beta,unstable
Reply to this email directly or view it on GitHub:
#26 (comment)—
Reply to this email directly or view it on GitHub
#26 (comment).
Reply to this email directly or view it on GitHub:
#26 (comment)
from paket.
[<Test>]
let ``can support alpha version``() =
"1.2.3-alpha001" |> isInRange (DependenciesFileParser.parseVersionRequirement "1.2.3-alpha001") |> shouldEqual true
"1.2.3-alpha001" |> isInRange (DependenciesFileParser.parseVersionRequirement "1.2.3") |> shouldEqual false
"1.2.3-alpha003" |> isInRange (DependenciesFileParser.parseVersionRequirement ">= 1") |> shouldEqual false
"1.2.3-alpha003" |> isInRange (DependenciesFileParser.parseVersionRequirement ">= 1 prerelease") |> shouldEqual true
"1.2.3-alpha023" |> isInRange (DependenciesFileParser.parseVersionRequirement ">= 1 alpha") |> shouldEqual true
"1.2.3-alpha023" |> isInRange (DependenciesFileParser.parseVersionRequirement ">= 1 alpha rc") |> shouldEqual true
"1.2.3-alpha023" |> isInRange (DependenciesFileParser.parseVersionRequirement ">= 1 beta rc") |> shouldEqual false
[<Test>]
let ``can support rc version``() =
"1.2.3-rec003" |> isInRange (DependenciesFileParser.parseVersionRequirement ">= 1 prerelease") |> shouldEqual true
"1.2.3-rc2" |> isInRange (DependenciesFileParser.parseVersionRequirement ">= 1 alpha") |> shouldEqual false
"1.2.3-rc2" |> isInRange (DependenciesFileParser.parseVersionRequirement ">= 1 beta rc") |> shouldEqual true
"1.2.3-rc2" |> isInRange (DependenciesFileParser.parseVersionRequirement ">= 2 beta rc") |> shouldEqual false
works
from paket.
next step is to parse this from nuget's package dependency syntax.
from paket.
+1
Alex
Alexander Groß
Tiny phone, tiny mail
On Wed, Sep 24, 2014 at 8:12 PM, Steffen Forkmann
[email protected] wrote:
next step is to parse this from nuget's package dependency syntax.
Reply to this email directly or view it on GitHub:
#26 (comment)
from paket.
Might be worth spending time future proofing while hair on fire :P http://blog.nuget.org/20140924/supporting-semver-2.0.0.html
from paket.
Related Issues (20)
- Paket does not use global nuget cache directory set in environment variable
- paket update hangs on switching git branch HOT 1
- Paket.Restore.targets error MSB4064: The "Readme" parameter is not supported by the "PackTask" task loaded from assembly: NuGet.Build.Tasks.Pack, Version=5.6.0.5,
- Paket outdated minor versions?
- `paket.exe restore` hangs after (successfully) finishing its job HOT 17
- `paket.exe` never returns (even when just using `paket.exe --version`)
- CVE-2018-8292 : System.Net.Http [referenced by Steeltoe.Management.CloudFoundryCore(3.2.3)]
- Dependency wrongly parsed
- dotnet pack --symbols fails with error about Compile entry not containing Update or Include attribute
- Paket Restore Targets doesn't work with .NET 6+ HOT 3
- .Net-Framework 4.8.1 not selectable
- Paket does not respect compatible versions of .Net Standard when adding references
- References to delisted versions of Nuget.Packaging
- Paket failing when trying to install dependencies `OpenSslCryptographicException` HOT 2
- Allow updating a transitive dependency HOT 1
- feat!(Paket.restore.targets): Support `dotnet restore` without `paket restore`; avoid null git diffs
- Empty response is not trusted?
- Paket Simplify Removing FSharp.Core from paket.references
- improve use case of `restore` that would not restore anything due to framework restriction and project being with wrong/lower framework version HOT 3
- plans for .NET 9 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from paket.