Giters

nodejs / ci-config-travis

Auto-updated Node.js version matrix in Travis CI

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add configurations which include N.0.0 releases

dominykas opened this issue · comments

commented

Original point raised in #6 (comment) (and subsequent discussion in the PR)

Strictly speaking, even though the general recommendation is to always run the latest version of Node.js in production, and even though older versions in any Node.js major release are considered unsupported, the declaration of "engines": ">= N" in package.json implies that the package should work in N.0.0.

This means that people should test in N.0.0 to avoid accidentally breaking downstream users by using features available only in the latest releases and we could possibly try to find a way to provide such a configuration.

Some discussion points:

  • Should we evangelize this to be the default in the ecosystem (and move on to include N.0.0 in future gte-N.yml files)?
  • Should we do it at all? Some package maintainers are likely to just bump major (as they should) when they introduce breaking changes (new minimum Node.js version requirement) and move on. This means that they should likely manually update their build matrix to include the minimum supported version explicitly - it is infeasible to provide all possible minimum version configurations.
  • Does the "all minors" config (#10) solve the issue well enough to not bother with a separate config?
  • Similar decision needed in #10 - should we use a subfolder or a file suffix for this configuration?
  • Naming (be it a new strategy, or a folder, or a suffix)
  • Do we need to include the N.0.0 for each major release line in the matrix? Can we get away with just one extra build job with the very earliest N.0.0 (which by definition will break if you try to use features from (N+1).0.0)?
  • Does semver need a way to define a range which asks for a latest (known) version, rather than all versions greater than N? See also: nodejs/package-maintenance#393
commented

I've certainly done this manually on a couple packages, but I've not found it to be necessary on hundreds of others.

(I think we would need to have an N.0.0 for every N, not just one overall)