nodejs / ci-config-travis Goto Github PK
View Code? Open in Web Editor NEWAuto-updated Node.js version matrix in Travis CI
License: MIT License
Auto-updated Node.js version matrix in Travis CI
License: MIT License
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:
gte-N.yml
files)?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
)?N
? See also: nodejs/package-maintenance#393Initial discussion: #6 (comment)
At the very least, there should be something, which can verify whether all the Travis imports are parseable and validate on Travis while still in PR stage.
We are going through all of the node.js repositories to rename the primary branch to main. Please see nodejs/node#33864 for more context.
I don't think there should be any issues for the contributors to this repo. I'd like to do the remain this Friday May 22nd unless there are any concerns.
Please let me know in this issue before May 22nd if there are any concerns, otherwise I'll go ahead and do the change.
Background: the intent of this repo is to provide a set of shared configurations that package maintainers can use in their .travis.yml
to automatically add new Node.js versions to their test matrix.
Here's my proposal for the repo layout:
[strategy]/
(see below)
README.md
(explain the policy/strategy, include a table of when a new version would be added into each config [and dropped in case of "support LTS, but also test in current" policy], add some examples)gte-N.yml
(major versions, starting with N, not sure what minimum N do we want to have when we start this - 0.8? 4? 8? 10?)I'm thinking we need to support the following strategies:
all
all
, active
, supported
, current
lts
lts
, lts_active
, lts_latest
lts/strict
(I'm thinking of hiding this in a subfolder, to nudge people towards the "support LTS, but also test in current" approach)
Possible extensions:
[strategy]/minors
sub-folder or gte-N-minors.yml
suffix? (I think I favor the sub-folder)Some guarantees we should provide:
Other observations:
master
, it is never breaking; if we need to break it - I'm thinking we should restart in a brand new repo?This came out of a discussion during nodejs/package-maintenance#379 meeting.
We've agreed in pkgjs that we recommend to bump semver major when dropping support for a specific node version, so that's why the initial proposal in #5 does not automatically remove the versions that people test in.
That said, part of the intent of this repository is to reduce the maintenance burden and so changing the gte-N
import could be considered a minor hassle. We might want to offer a config which you simply import, and it automatically drops the node versions that are no longer maintained (possibly with a delay?).
I know this could be a contentious discussion, so I'm splitting this out of #5.
Some folks would likely want to have a larger test matrix based on their version support needs, at the cost of slower builds / more build minutes.
As suggested in #5, this could be done as a sub-folder inside a strategy folder, or it can be done as a suffix, e.g. gte-N-minors.yml
.
This could somewhat address the "people should test in N.0.0" case (for packages that declare their engines
support as >= N
/ N.x
), to avoid accidentally breaking downstream users by using features available only in the latest releases (points raised in #6 (comment) and the remaining discussion).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.