Repo layout bikeshed

[dominykas]

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
  • support levels: all, active, supported, current
  • adds a new major as soon as it is released
  • never removes majors
• lts
  • support levels: lts, lts_active, lts_latest
  • adds a new major as soon as it is released
  • removes non-LTS majors as soon as they stop being supported; this is OK, as there is no support for these versions - but the recommendation is to still use them for testing (to spot regressions early)
• lts/strict (I'm thinking of hiding this in a subfolder, to nudge people towards the "support LTS, but also test in current" approach)
  • adds a new major when it enters LTS
  • never removes majors

Possible extensions:

• Include minor versions - not sure this is necessary for the initial version? But it could be added as [strategy]/minors sub-folder or gte-N-minors.yml suffix? (I think I favor the sub-folder)
• An in-between strategy for LTS - only add majors which will become LTS eventually, but do it as soon as they are released

Some guarantees we should provide:

• Once a version is added into the matrix, it is never removed (except for the strategy where it explicitly only adds "current" for testing purposes).
• Once an include file is created, it is never removed

Other observations:

• Versioning this does not make sense - there's only master, it is never breaking; if we need to break it - I'm thinking we should restart in a brand new repo?
• Unsure whether the tooling to generate the ymls needs to live in this repo or separately? I'm leaning towards keeping it separately, but that might be harder for folks who need support to follow?

[dominykas]

Ping @ljharb - I know you might have some opinions on this...