paulononato/backstage
1
0
Fork 0
Code Issues Pull Requests Actions 31 Packages Projects Releases Wiki Activity

Merge pull request #12217 from backstage/rugvip/node-releases

Browse Source 
docs: add node release section to versioning policy
This commit is contained in:
Patrik Oldsberg
2022-06-23 09:18:30 +02:00
committed by GitHub
parent 02fd2c6ba2 32c03c6a69
commit 5548f956d9
1 changed files with 18 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/overview/versioning-policy.md
+18
View File
@@ -135,3 +135,21 @@ package export.
accessed via `<package-name>/beta` or `<package-name>/alpha` imports.
- `@alpha` - here be dragons. Not visible in the main package entry point, alpha
exports must be accessed via `<package-name>/alpha` imports.
## Node.js Releases
The Backstage project uses [Node.js](https://nodejs.org/) for both its development
tooling and backend runtime. In order for expectations to be clear we use the
following schedule for determining the [Node.js releases](https://nodejs.org/en/about/releases/) that we support:
- At any given point in time we support exactly two adjacent even-numbered
releases of Node.js, for example v12 and v14.
- Three months before a Node.js release becomes _Active LTS_ we switch support
to that release and the previous one. This is halfway through the _Current LTS_
cycle for that release and occurs at the end of July every year.
When we say _Supporting_ a Node.js release, that means the following:
- The CI pipeline in the main Backstage repo tests towards the supported releases, and we encourage any other Backstage related projects to do the same.
- New Backstage projects created with `@backstage/create-app` will have their `engines.node` version set accordingly.
- Dropping compatibility with unsupported releases is not considered a breaking change. This includes using new syntax or APIs, as well as bumping dependencies that drop support for these versions.