Skip to content

Communicating that only the latest version of a major release line is supported #393

Open

Description

@dominykas

This came up in discussions in nodejs/ci-config-travis#6.

When people say they support e.g. Node 14.x, the usually (is that true?) mean that they only support the latest version in the 14.x line. At this time neither semver, nor PACKAGE-SUPPORT allows to define that as such?

Should we clarify that in the PACKAGE-SUPPORT doc?

Ideally, one would be able to communicate that via engines as well, but moving the semver standard might be trickier (if possible at all).

Activity

  1. mhdawson commented on Jul 30, 2020

    @mhdawson
    Member

    In the PACKAGE_SUPPORT.md I think the assumption (at least for me) is that the maintainer has said lts, 'active`, etc if you need updates they will only come in the next minor or patch release for the lines that they relate to.

    So for example if you've chosen lts_latest and the latest LTS is currently 12.x that means effectively that if you have any problems in anything other than the latest 12.x release you'll have to upgrade to the latest.

    But I guess that is different than which versions the package itself will work with and it is possible that a package might only work for a subset of the 12.x versions. In that case though you could use the engines so say it only runs on 12.5 or later.

    It is an interesting question. If a module consumes a SemVer patch release of Node.js that forces users to update their Node.js version if they consume corresponding SemVer Patch version of the module.

    I guess the question is if there needs some way for maintainers to say for a given LTS release line I won't use any of the SemVer minor features so you won't have to update Node.js when accepting SemVer minor/patch versions of the module. That actually sounds useful for end users, but I'm not sure I've seen that being done, except possibly in cases where people like @ljharb tries to support as far back as he can.

  2. ljharb commented on Jul 31, 2020

    @ljharb
    SponsorMember

    Explicitly in semver tho, 14.x means any 14, including 14.0.0. There is no way in semver or npm to specify the latest minor on a major dynamically.

  3. ghinks commented on Aug 4, 2020

    @ghinks
    Contributor

    Unfortunately I too have always interpreted 14.x by the semver definition as above. Is it a common interpretation to think of this as latest?

  4. lholmquist commented on Aug 4, 2020

    @lholmquist
    Contributor

    i assumed the same thing as well. I think of 14.x to be all of 14

  5. dominykas commented on Aug 4, 2020

    @dominykas
    MemberAuthor

    Adding to next meeting agenda, let's talk this over.

  6. dominykas commented on Aug 25, 2020

    @dominykas
    MemberAuthor

    Actions for @dominykas:

    • readme update in ci-config-travis to explicitly explain this
    • update the package support doc to note that any support upgrading to latest version of a release line (unless stated otherwise?)
  7. dominykas commented on Aug 31, 2020

    @dominykas
    MemberAuthor

    Included a note about this issue in nodejs/ci-config-travis#12.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions