Ignore Major Versions
Major version releases should be optionally ignored. I would like to scope a gem to a supported version range, that may not be the latest version.
For example, several of our projects use Rails 3, but Gemnasium says that it's outdated, even though it's supported at 3.2.17 right now, simply because Rails 4.0.3 is out.
This is just one example, and occurs for lots of software regularly.
Thanks for the idea, it really makes sense, so we’re starting to evaluate how to implement this.
Björn Schneider commented
You might use comments along with the version definitions, like requires.io (Python) does. In pip's requirements.txt you would write something like:
Django==1.8.9 # gn.version>1.8.0,<1.9.0 gn.expires=2018-04-01
...which means "pin it to a version between 1.8.0 and 1.9.0" (that's a long term support version), but warn after April, 1st 2018 (when the support runs out).
Similar schould work for other build systems, unfortunately not for npm - JSON files can't contain comments. Here you'd need to use an own sub-key, e.g.:
...which would warn after July, 1st 2018 if you still use a 2.7 version of wepack.
That's for the two packaging systems/languages I use and need support for. But I guess there are similar options for the other ones supported by Gemnasium.
You should really provide an option to behave like `bundle outdated --strict`.
Sometimes one pin a gem to a specific version because his code is not compatible with the next (either minor or major) version.
Or maybe the new version has an issue that prevent your code to work as expected.
Bundle already handle this, with `bundle outdated --strict`
Ideally gemnasium should resemble the output of the previous command. It should only warn when current dependencies have security issues, otherwise badge should be green if command output is empty.
this is seriously annoying as for node some repos major version bump is a need to know and others it's like node where only even versions are stable so it's better left to the owner.
Jonathan W. Zaleski commented
+1 -- I would love to see this resolved as my organization is still developing on Rails 3.2.x as well
Aleks “f” Marks commented
Scott Cranfill commented
As another example: We don't want to upgrade to jQuery 2 because it drops support for IE8. We'd prefer to only be notified of updates to the 1.x line of releases.