1 | ## Maintenance & Support Policy
|
2 |
|
3 | This document describes the Maintenance & Support Policy applicable to releases
|
4 | of the `jsii` compiler ([`npm:jsii`](https://npmjs.com/packages/jsii)) with
|
5 | versions `5.0.x` and newer.
|
6 |
|
7 | ### Versioning Scheme
|
8 |
|
9 | In-scope `jsii` release lines use the same `major.minor` version as the
|
10 | TypeScript compiler ([`npm:typescript`](https://npmjs.com/packages/typescript))
|
11 | they are built with. This means that `jsii@5.0.x` is built on top of
|
12 | `typescript@5.0.x`.
|
13 |
|
14 | Since the `typescript` package does not follow [Semantic Versioning][semver],
|
15 | the `jsii` package does not eiher. The `typescript` compiler guarantees no
|
16 | breaking change is introduced within a given `major.minor` release line, and
|
17 | `jsii` upholds the same guarantee. As a consequence, users are advised to use
|
18 | `~` ranges (also referred to as minor-pinned ranges) when declaring dependencies
|
19 | on `jsii`.
|
20 |
|
21 | New `jsii` release lines will be started matching new `typescript` compiler
|
22 | releases shortly after they become `latest` (i.e: the first regular release of
|
23 | is issued).
|
24 |
|
25 | [semver]: https://semver.org
|
26 |
|
27 | ### Release Lines Lifecycle Stages
|
28 |
|
29 | This Maintenance & Support Policy assigns one of the following lifecycle stages
|
30 | to each in-scope `jsii` release line in existence:
|
31 |
|
32 | 1. **Current**: The latest release line is always the **Current** one. This is
|
33 | the release under active development, receiving new features, bug fixes and
|
34 | security updates.
|
35 |
|
36 | 1. **Maintenace**: Release lines in **Maintenance** stage are no longer
|
37 | considered in active development, and no new features will be added to these.
|
38 | They however continue to receive bug fixes and security updates. Users can
|
39 | continue to use release lines in **Maintenance** stage indefinitely, but we
|
40 | recommend they regularly upgrade to the **Current** release lines in order to
|
41 | keep the necessary effort low.
|
42 |
|
43 | 1. **End-of-Support**: Release lines in **End-of-Support** are considered
|
44 | defunct and are no longer maintained. They no longer receive new features,
|
45 | bug fixes, or security updates. **End-of-Support** releases may continue to
|
46 | be usable for a period of time, but they could be indirectly broken by
|
47 | changes in newer releases at any time. Users are advised to migrate away from
|
48 | **End-of-Support** release lines at the earliest convenience.
|
49 |
|
50 | ### Stage Transitions
|
51 |
|
52 | ```mermaid
|
53 | ---
|
54 | title: Release Line Lifecycle
|
55 | ---
|
56 | stateDiagram-v2
|
57 | direction LR
|
58 |
|
59 | EoL: End-of-Support
|
60 |
|
61 | [*] --> Current
|
62 | Current --> Maintenance : new release line started
|
63 | Maintenance --> EoL : after 6 months
|
64 | EoL --> [*]
|
65 | ```
|
66 |
|
67 | Whenever a new release line is started (typically with a new `x.y.0` release,
|
68 | excluding pre-releases), it becomes **Current** and the release line it replaced
|
69 | immediately enters the **Maintenace** stage.
|
70 |
|
71 | Releases stay in the **Maintenance** stage for a minimum of 6 months before they
|
72 | reach **End-of-Support**.
|
73 |
|
74 | Once a release line has reached **End-of-Support**, it remains in this stage
|
75 | indefinitely.
|
76 |
|
77 | ### Timelines & Communication
|
78 |
|
79 | The `typescript` compiler maintainers start a new release line on a quarterly
|
80 | basis, and users should expect the `jsii` compiler maintainers to do the same.
|
81 | Users should expect some small code changes may be necessary when upgrading from
|
82 | one release line to another, as a result of breaking changes introduced by the
|
83 | `typescript` compiler or `jsii` itself. In either case, the release notes for
|
84 | the first release in a line includes the relevant information about the breaking
|
85 | changes and instructions for users to fix their codebase.
|
86 |
|
87 | The `jsii` compiler has a built-in mechanism to inform users that they are using
|
88 | an unsupported or soon-to-become unsupported release line. A message is emitted
|
89 | to `STDERR` when invoking the `jsii` command if the current release is:
|
90 |
|
91 | - **End-of-Support** already
|
92 | - Planned to move to **End-of-Support** within the next 30 calendar days
|
93 |
|
94 | The built-in messaging can only be expected to deliver the message if the
|
95 | compiler is on the latest available release within the line, or if the
|
96 | environment in which the compiler is run is able to download the lifecycle
|
97 | manifest document.
|
98 |
|
99 | The current status of `jsii` compiler release lines is also documented on the
|
100 | [repository's `README.md` document][readme].
|
101 |
|
102 | ### Modification
|
103 |
|
104 | The maintainers of the jsii project reserve the right to modify this Maintenance
|
105 | and Support Policy as necessary. Updates will be proposed by way of a pull
|
106 | request updating this document. Updates that materially affect the support
|
107 | timeline of release lines will be broadly announced to the community via
|
108 | established communication channels (such as the `cdk.dev` Slack), and will
|
109 | remain open for the community to comment on for a minimum of 15 days.
|
110 |
|
111 | Community members are welcome to propose changes to the support and maintenace
|
112 | policy through the same process.
|
113 |
|
114 | ### Derogation
|
115 |
|
116 | Under _exceptional_ circumstances, the project maintainers may elect to derogate
|
117 | from this Support & Maintenance Policy. In cases where the decisision to
|
118 | derogate extends supplemental maintenance & support coverage for a release line,
|
119 | the increased coverage will be documented in the
|
120 | [repository's `README.md` document][readme].
|
121 |
|
122 | However, in situations where the derogation results in reduced support for one
|
123 | or more release lines, the decision to derogate is considered a "break glass"
|
124 | event and maintainers will document the motivation for the derogation, as well
|
125 | as provide the post-mortem analysis to determine and address the reason
|
126 | why this decision has to be taken, including an action plan put in place to
|
127 | ensure the same situation does not occur again in the future.
|
128 |
|
129 | [readme]: ./README.md
|