I suggest you ...

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.

58 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Dan MooreDan Moore shared this idea  ·   ·  Admin →

    8 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Björn SchneiderBjö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.:
        ...
        "dependencies": {
        "webpack": "^2.7.0"
        },
        "gemnasium": {
        "webpack: {
        "expires": "2018-06-01"
        }
        },
        ...

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

      • FabioFabio commented  · 

        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.

      • GabeGabe commented  · 

        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. ZaleskiJonathan W. Zaleski commented  · 

        +1 -- I would love to see this resolved as my organization is still developing on Rails 3.2.x as well

      • Scott CranfillScott 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.

      Feedback and Knowledge Base