Support for version pattern matching (for installing, updating, and specifying dependencies)

[cparker15]

It would be nice if I could specify only a major version or a minor version when I request a package to install.

For example, I need to install the latest stable Ruby 1.x (currently 1.9.3-p448). (Ruby 2.x is not backward-compatible with 1.x; I need to stay with 1.x.)

I should be able to issue the install command like one of the following:

cinst ruby -version "1.x"
cinst ruby -version "~1"
cinst ruby -version "1.9.3"
cinst ruby-version "1.9.x"
cinst ruby -version "~1.9"
cinst ruby -version "<2"

However, I'm stuck specifying the tiny/patch level, too.

cinst ruby -version 1.9.3.44800

When the next patch is released, this leaves me without the ability to automatically keep my Ruby 1.x install up-to-date using a command such as this:

cup ruby -version "1.x"
cup ruby -version "~1"
cup ruby -version "1.9.3"
cup ruby-version "1.9.x"
cup ruby -version "~1.9"
cup ruby -version "<2"

(My examples have been heavily influenced by npm's semver support. See https://npmjs.org/doc/misc/semver.html)

[kopelli]

Is there any reason for the install of the package manually versus relying on the NuSpec dependencies? If you listed the package as a dependency with a constraint on the version I would think it should fit the need. It's possible by having the dependencies node look something like this:

        <dependencies>
            <dependency id="ruby" version="[1, 2)" />
        </dependencies>

This means that you require Ruby >= 1 and < 2 (so all updates and minor patches up until, and not including, version 2).

[ferventcoder]

Correct me if I'm wrong but the OP is asking for this requirement when
specifying a package to install (user use case), not when taking a
dependency on another package (creator use case).

On Thursday, October 24, 2013, Steve E wrote:

Is there any reason for the install of the package manually versus relying
on the NuSpec dependencies? If you listed the package as a dependency with
a constraint on the version I would think it should fit the need. It's
possible by having the dependencies node look something like this:

    <dependencies>
        <dependency id="ruby" version="[1, 2)" />
    </dependencies>

This means that you require Ruby >= 1 and < 2 (so all updates and minor
patches up until, and not including, version 2).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/346#issuecomment-27014735
.

---

Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

[rismoney]

agree with you ferventcoder- that was my understanding.

i think its a metric s-ton of a parsing exercise that probably needs to start with TDD via pester, and make each use case pass... just looking at this readme https://github.com/isaacs/node-semver made my head hurt.

[gep13]

There is a .Net Class for SemVer in the nuget code base, I wonder if we could re-use that.

Sent from my Windows Phone

---

From: Rich Siegelmailto:notifications@github.com
Sent: ‎25/‎10/‎2013 02:04
To: chocolatey/chocolateymailto:chocolatey@noreply.github.com
Subject: Re: [chocolatey] Support for version pattern matching (for installing, updating, and specifying dependencies) (#346)

agree with you ferventcoder- that was my understanding.

i think its a metric s-ton of a parsing exercise that probably needs to start with TDD via pester, and make each use case pass... just looking at this readme https://github.com/isaacs/node-semver made my head hurt.

---

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

[mwrock]

Yeah that would be nice. I had started to do that on a related spike a while back and then realized that because it is .net 4, it requires at least PS 3 in order to call directly from powershell.

From: Gary Ewan Park [mailto:notifications@github.com]
Sent: Thursday, October 24, 2013 9:24 PM
To: chocolatey/chocolatey
Subject: Re: [chocolatey] Support for version pattern matching (for installing, updating, and specifying dependencies) (#346)

There is a .Net Class for SemVer in the nuget code base, I wonder if we could re-use that.

Sent from my Windows Phone

---

From: Rich Siegelmailto:notifications@github.com
Sent: ‎25/‎10/‎2013 02:04
To: chocolatey/chocolateymailto:chocolatey@noreply.github.com
Subject: Re: [chocolatey] Support for version pattern matching (for installing, updating, and specifying dependencies) (#346)

agree with you ferventcoder- that was my understanding.

i think its a metric s-ton of a parsing exercise that probably needs to start with TDD via pester, and make each use case pass... just looking at this readme https://github.com/isaacs/node-semver made my head hurt.

---

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

—
Reply to this email directly or view it on GitHub #346 (comment) . https://github.com/notifications/beacon/SVpp0Doaws5T1aBsNeEOjuhn4qSMKcvXexQ8DxDMiWxbwLGbXJX0oqylR61aZFj8.gif

[cmshawn]

I'll give another example to illustrate OP's need. I own a license for ReSharper 7.x, but not 8.x. I'd like to use chocolatey to make sure I have the latest bug-fix releases for 7 (using cup all) but if I get bumped up to 8 I'll no longer be licensed.

[cmshawn]

Duplicate of #5?

[jberezanski]

In the Resharper case, I'd argue that major versions (with non-transferable licenses) should be released as different packages, e.g. resharper7 and resharper8.

[kopelli]

Deviating from the topic, but if I see multiple major versions of a product as separate packages, I'd assume they can be installed side by side and have no impact on each other (and can be installed in whichever order the user wants). That's not the case with an add-in like ReSharper.

So the need is definitely still there.

[jberezanski]

Good point. But in that case, the burden of preventing an unwanted/potentially breaking update should ideally lie with the package author, not the user. I.e. the 7.x package should somehow indicate in its metadata that it should not be automatically updated to 8.0 or higher. (But this is more in the topic of #5.)

[ferventcoder]

@jberezanski I think that would work fine but would need some testing - if someone had a meta package installed named resharper7.x that took a dependency on resharper, it may keep it at 7, but it may not... worth some testing in the new codebase.