We need support for NuGet prereleases

[forki]

No description provided.

[forki]

how would this look like?
@ilkerde @agross

[agross]

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 notifications@github.com
wrote:

how would this look like?

@ilkerde @agross

Reply to this email directly or view it on GitHub:
#26 (comment)

[forki]

so how would this look like?

2014-09-09 18:58 GMT+02:00 Alexander Groß notifications@github.com:

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 notifications@github.com

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).

[ilkerde]

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 ?

[agross]

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 notifications@github.com 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"
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 ?

Reply to this email directly or view it on GitHub:
#26 (comment)

[forki]

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

[agross]

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?

[forki]

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

[agross]

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
notifications@github.com 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)

[forki]

Yep
On Sep 24, 2014 6:51 PM, "Alexander Groß" notifications@github.com wrote:

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
notifications@github.com 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).

[agross]

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
notifications@github.com wrote:

Yep
On Sep 24, 2014 6:51 PM, "Alexander Groß" notifications@github.com wrote:

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
notifications@github.com 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)

[forki]

[<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

[forki]

next step is to parse this from nuget's package dependency syntax.

[agross]

+1

Alex

Alexander Groß
Tiny phone, tiny mail

On Wed, Sep 24, 2014 at 8:12 PM, Steffen Forkmann
notifications@github.com 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)

[bartelink]

Might be worth spending time future proofing while hair on fire :P http://blog.nuget.org/20140924/supporting-semver-2.0.0.html