Support Version Ranges

[cdemi]

It would be awesome if LibMan could support Library version ranges. Maybe something similar to npm semver ranges?

[justcla]

What scenarios are you trying to cover?
In which instances would you want a version range, and why?
If you could tell us the most important reasons for the feature, it will help us evaluate how useful it would be. Thanks.

[cdemi]

For example, I could say I would want to stay on major version 4 of a library. So if other minor or patch versions are released on every build I would have the latest update of the library as long as it's the same major version

[justcla]

To assist the discussion, I'll mention that we considered this when designing LibMan. We decided that the libman.json should specify exact versions of library and the primary reason was so that a user downloading the project from source control in two years time would be ale to ensure they get the correct versions of the required packages, as updates in the latest version of the libraries might be incompatible with their app code.

That being said, if the project author wanted to take the risk that newer versions will not break the app, then they could potentially declare a range, and LibMan would pull the latest stable version from that range.

We definitely don't want to get involved with full package management. That's a job that's already well handled by npm. LibMan is not intended to be a package management system. It's primary purpose it to help web developers find and acquire common javascript/css client-side libraries. For all other things, npm has it covered.

[cdemi]

You have a point. Maybe version ranges would be out of scope if it's handled well by others, but would you consider something as simple as 4.*.*? Or maybe following NuGet Version ranges and wildcards?

[justcla]

I think what you've listed is a valid scenario (staying on major version 4). It's equally a risky scenario.
4.. is really just another way of specifying a version range. It carries the same risk, though hopefully less breaking changes.

Could we(/should we) give project authors the ability to specify a version range that could potentially break their app?

[cdemi]

I think it would be a good option to offer. (I think) nearly all package managers already implement something like this, for example, for me, before I even used LibMan I looked for how to do this on LibMan assuming that it already supports it.

My point is, I think project authors already know that this functionality if used incorrectly, may break their app, because it's mostly how we're already working with all of our other tools

[justcla]

I think it would be a good option to offer. (I think) nearly all package managers already implement something like this, for example, for me, before I even used LibMan I looked for how to do this on LibMan assuming that it already supports it.

Now now. LibMan is NOT a package manager. If you want package manager functionality, we recommend you use npm (or whatever other PM you like).

[justcla]

My point is, I think project authors already know that this functionality if used incorrectly, may break their app, because it's mostly how we're already working with all of our other tools

@jimmylewis This seems valid. What are your thoughts?

[jimmylewis]

I think our main concern here is that it opens a potential pitfall, in that Alice might clone and restore today and get CoolLibrary@4.0, and Bob might join the team next month, clone, and get CoolLibrary@4.1. Since we don't by default always check for updates (unless you opt in to a restore-on-build behavior, which isn't the default), Alice won't get updated until she somehow forces a refresh. If Bob adds a feature dependent on CoolLibrary@4.1, then they could end up in a "Works on my machine" debacle until they can track down the difference.

You're entirely right that package managers implement this, but they also do it to provide a sane dependency graph. They're also usually tied into the build, so devs are consistently up to date. We don't have a concept of dependencies, so we've tried to keep it simple and explicity (which also avoids the need to implement lock files... with our current behavior, libman.json is the lock file because the version is explicit).

As @justcla mentioned, we're not trying to replace npm, because we know it already provides rich functionality and we're not trying to improve upon it. Instead we're aiming at a lower concept cost of entry, but that also means supporting simpler functionality.

I think this is one that we'd currently consider this out of scope, unless we get more feedback that this would be desirable and that updating the version manually is not tenable.

[cdemi]

Fair enough. Would you consider, instead, warning on restore if you're not using the latest versions for example? Developers would need to manually upgrade versions in libman.json but at least they'd know that they running older versions.

Right now, the process is that you have to go to the libman file, click on every library, wait for the light bulb helper, click it and choose Check for Updates. Which has to be done manually (and slowly).

[jimmylewis]

That's a great idea. We should also have a way to suppress it (e.g. "Stop telling me about bootstrap v4, my site uses v3"), but I think it's a very reasonable feature.

[jimmylewis]

I'm going to close this issue in favor of #384, which gets succinctly to the feature you suggested at the end of this thread. Let me know if you disagree.