Release schedule
4 minute read
API Builder lifecycle
Major versions of API Builder are supported for a minimum of two years. Each major version is designated by an incremental number, e.g. v4, v5, etc. Every year around September, a new major version of API Builder will be introduced and it will enter into an Active development phase, and the previous major version will leave Active development phase and enter Maintenance phase.
Each new major version will follow a two-week release plan where each release is named after an alphabetical collection of nouns. The v4 releases were named after cities. The v5 releases will be named after authors. Release names for subsequent releases will be decided later.
The current release schedule is as follows:
Releases
As with any software, it is important to keep up all components up to date. The Updates tab in API Builder can be used to keep API Builder up to date.
Similarly, there will be important security releases for Node.js. These versions will often have fixes for web related vulnerabilities which are very important to when running an API Builder service. We strongly recommend to keep an eye on the Node.js blog for new security releases and stay up-to-date to keep your service secure. API Builder will update the recommended Node.js version when we add support, and as new security releases become available.
Any API Builder major version that is currently supported can introduce or deprecate support for specific Node.js versions as required, according to Node.js release schedule.
API Builder Core
Below are all the major Core versions and their current status and requirements.
| Core version | Status | Release Names | Minimum Node.js | Recommended Node.js | Active Start | Maintenance Start | Support Stop |
|---|---|---|---|---|---|---|---|
| v4 | Maintenance | Cities | v8.9.0 | v16 | 2018-06-29 | 2022-09-09 | 2023-09-09 |
| v5 | Active | Authors | v16 | v16 | 2022-09-09 | 2023-09-09 | 2024-09-09 |
API Builder CLI
Below are the major CLI versions and their current status and requirements. Note that each CLI version should be used alongside the particular version of API Builder Core as shown below.
| CLI version | API Builder Core version | Status | Minimum Node.js | Active Start | Maintenance Start | Support Stop |
|---|---|---|---|---|---|---|
| v6 | v4 | Maintenance | v12.17.0 | 2018-06-29 | 2022-09-09 | 2023-09-09 |
| v7 | v5 | Active | v16 | 2022-09-09 | 2023-09-09 | 2024-09-09 |
Active development phase
Major API Builder versions are in Active development for at least 12 months. In Active development, releases happen every two weeks, and may contain any of the following:
- New features
- New components
- New feature deprecations
- Fixes
- Security updates
Whenever possible, we encourage you to use the latest version of API Builder by regularly applying all available updates and upgrades to your projects, and to contact support if any issues arise in doing so.
In this phase, features may be deprecated. If you see warnings in the console, you may be using a feature that is intended to be changed or removed from the product in a future major release. You should endeavor to resolve the deprecation warnings. In most cases, it may be enough to add a deprecation flag to the configuration. You can read more about when deprecated features are planned to be removed from the product in the Major version compatibility policy section below.
Maintenance phase
When a new major version of API Builder is released, previous major versions enter the Maintenance phase, where the product is actively maintained and supported, but releases happen much less regularly, and may contain any of the following:
- Fixes
- Security updates
It is policy that deprecations are not introduced in the Maintenance phase. Major versions of the product will remain in the Maintenance phase for 12 months, after which, the Major version is no longer supported.
Major version compatibility policy
Each major version will have a number of breaking changes from the previous version, but our intention is that it should be as easy as possible to upgrade from one major version to the next. We give users the opportunity to opt-in to breaking changes at their own leisure by deprecating old behavior well in advance of a breaking change being introduced in a future major version.