|
| 1 | +# Maintenance Announcement: `jsii` & `jsii-rosetta` 1.x |
| 2 | + |
| 3 | +**Announcement Date:** `2023-04-24` |
| 4 | + |
| 5 | +We have recently released `jsii@5.0.0` and `jsii-rosetta@5.0.0`, built on the TypeScript `5.0.x` compiler, allowing |
| 6 | +package maintainers to migrate to a more modern TypeScript language version than 3.9 (which the `1.x` release line is |
| 7 | +built on). This change was designed in [RFC-374], and removes the need for developers to pin some of their dependencies |
| 8 | +to releases still compatible with TypeScript 3.9 without necessarily requiring their dependents to do the same at the |
| 9 | +same time. Upgrading your `jsii` and `jsii-rosetta` dependencies to `v5.0.x` is transparent to your users. |
| 10 | + |
| 11 | +[RFC-374]: https://github.com/aws/aws-cdk-rfcs/blob/rmuller/jsii-version-unlock/text/0374-jsii-ts-version.md |
| 12 | + |
| 13 | +Starting with the `5.0.x` release of `jsii` and `jsii-rosetta`, we are using a new versioning strategy for these two |
| 14 | +tools. Going forward we will closely follow new TypeScript compiler releases with new `jsii` and `jsii-rosetta` releases, |
| 15 | +enabling the entire jsii developer community to adopt new TypeScript syntax & benefit from bug fixes and |
| 16 | +performance enhancements brought into the TypeScript compiler, while retaining the ability control the timeline of these |
| 17 | +upgrades. |
| 18 | + |
| 19 | +We believe the new versioning strategy will result in an improved developer experience for jsii library maintainers, and |
| 20 | +have decided to start the process of retiring the `1.x` release line. In accordance with our maintenance commitment for |
| 21 | +the `1.x` release line, the retirement timeline is the following: |
| 22 | + |
| 23 | +* On `2023-04-24`, `jsii@1.x` and `jsii-rosetta@1.x` will enter the **Maintenance Announcement** stage. During this |
| 24 | + stage, they will continue to be actively maintained, including new features back-ported from the current release |
| 25 | + (`5.0.x` or later), bug fixes, and security updates. |
| 26 | +* On `2023-10-31` (six months later), the releases will move into the **Maintenance** stage. During this stage, they |
| 27 | + will continue receiving bug fixes and security updates, but will no longer receive new features. |
| 28 | +* On `2024-10-31` (one year later), the releases will finally reach **End-of-Support**, and will no longer receive any |
| 29 | + features, bug fixes, or security udpates. |
| 30 | + |
| 31 | +Future `1.x` releases of `jsii` and `jsii-rosetta` will soon start displaying a warning when used, encouraging customers |
| 32 | +to migrate to the newer releases, which we believe will provide a better experience. |
| 33 | + |
| 34 | +## Frequently Asked Questions |
| 35 | + |
| 36 | +### How difficult is it to migrate from `1.x` to `5.0.x`? |
| 37 | + |
| 38 | +The TypeScript language incurred a number of breaking changes between 3.9 and 5.0, including the following: |
| 39 | + |
| 40 | +* Catch bindings are typed as `unknown` by default instead of being implicitly `any` |
| 41 | + * You may need to explicitly type catch bindings as any: `catch (e)` → `catch (e: any)` |
| 42 | +* It is no longer allowed to declare abstract methods `async` |
| 43 | + * Simply remove the `async` keyword from `abstract` method declarations |
| 44 | +* Additional breaking changes may affect your code, and you can read more about these on the TypeScript release notes |
| 45 | + for the respective versions: |
| 46 | + * [TypeScript 4.0 release notes](https://devblogs.microsoft.com/typescript/announcing-typescript-4-0/) |
| 47 | + * [TypeScript 4.1 release notes](https://devblogs.microsoft.com/typescript/announcing-typescript-4-1/) |
| 48 | + * [TypeScript 4.2 release notes](https://devblogs.microsoft.com/typescript/announcing-typescript-4-2/) |
| 49 | + * [TypeScript 4.3 release notes](https://devblogs.microsoft.com/typescript/announcing-typescript-4-3/) |
| 50 | + * [TypeScript 4.4 release notes](https://devblogs.microsoft.com/typescript/announcing-typescript-4-4/) |
| 51 | + * [TypeScript 4.5 release notes](https://devblogs.microsoft.com/typescript/announcing-typescript-4-5/) |
| 52 | + * [TypeScript 4.6 release notes](https://devblogs.microsoft.com/typescript/announcing-typescript-4-6/) |
| 53 | + * [TypeScript 4.7 release notes](https://devblogs.microsoft.com/typescript/announcing-typescript-4-7/) |
| 54 | + * [TypeScript 4.8 release notes](https://devblogs.microsoft.com/typescript/announcing-typescript-4-8/) |
| 55 | + * [TypeScript 4.9 release notes](https://devblogs.microsoft.com/typescript/announcing-typescript-4-9/) |
| 56 | + * [TypeScript 5.0 release notes](https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/) |
| 57 | + |
| 58 | +In addition to these, two import changes affect jsii exported APIs specifically: |
| 59 | + |
| 60 | +* The `1.x` release line silently ignores index signatures (these are hence unavailable in other languages), and the |
| 61 | + `5.0.x` release starts explicitly rejecting these |
| 62 | + * You can explicitly opt into the `1.x` behavior by adding the `@jsii ignore` doc-tag: |
| 63 | + ```ts hl_lines="5" |
| 64 | + export interface Example { |
| 65 | + /** |
| 66 | + * This API is not visible in non-TS/JS languages. |
| 67 | + * |
| 68 | + * @jsii ignore |
| 69 | + */ |
| 70 | + readonly [key: string]: any; |
| 71 | + } |
| 72 | + ``` |
| 73 | + |
| 74 | +* The `1.x` release line incorrectly interprets tuple types as synonyms to `object` (resulting in those APIs often being |
| 75 | + unusable from other languages), and the `5.0.x` release starts explicitly rejecting these |
| 76 | + * These APIs need to be replaced. You can use the `@jsii ignore` doc-tag to explicitly opt these APIs out of the |
| 77 | + multi-language supported API, and provide an alternate API: |
| 78 | + ```ts hl_lines="3-4 8" |
| 79 | + export class Example { |
| 80 | + /** |
| 81 | + * @jsii ignore |
| 82 | + * @deprecated Prefer using `newMethod` instead. |
| 83 | + */ |
| 84 | + public method(): [string, number] { /* ... */ } |
| 85 | +
|
| 86 | + public newMethod(): StringAndNumber { /* ... */ } |
| 87 | + } |
| 88 | +
|
| 89 | + export interface StringAndNumber { |
| 90 | + readonly stringValue: string; |
| 91 | + readonly numberValue: number; |
| 92 | + } |
| 93 | + ``` |
| 94 | + |
| 95 | +### What happens with other packages of the jsii toolchain (`jsii-pacmak`, `jsii-config`, etc...)? |
| 96 | + |
| 97 | +The new versioning strategy only affects the `jsii` and `jsii-rosetta` packages. All other parts of the jsii toolchain |
| 98 | +will continue to be released under the `1.x` release line for the foreseeable future. The compilation artifacts produced |
| 99 | +by `jsii@5.0.0` and newer remain compatible with jsii tools from the `1.x` toolchain, so developers do not have to coordinate |
| 100 | +upgrades with their dependents and dependencies. |
| 101 | + |
| 102 | +### If I upgrade my package to `jsii@5.0.0`, are my dependents required to do the same? |
| 103 | + |
| 104 | +You can decide to upgrade your `jsii` compiler as well as `jsii-rosetta` independently from your dependencies and |
| 105 | +dependents. Output artifacts are compatible across all tool releases, including the `1.x` line, at least until they |
| 106 | +reach *End-of-Support*. |
| 107 | + |
| 108 | +### Can my app have dependencies built by different `jsii` release lines? |
| 109 | + |
| 110 | +The `jsii` compiler and `jsii-rosetta` versions used to build a library has no material impact on the runtime artifacts. |
| 111 | +The underlying runtime platform remains unchanged, and developers do not need to worry about which version of the |
| 112 | +compiler was used to produce their dependencies. |
| 113 | + |
| 114 | +### How often will new `jsii` & `jsii-rosetta` release lines be started? |
| 115 | + |
| 116 | +New releases will closely follow those of the TypeScript compiler, which are created approximately once per quarter. |
| 117 | +While we encourage customers to migrate to the latest release line as quickly as possible, the updated _Support & |
| 118 | +Maintenance Policy_ for these tools guarantees a minimum of six calendar months of bug fixes and security updates for |
| 119 | +non-current release lines, so that users can migrate on their own schedule. |
| 120 | + |
| 121 | +### What is the support policy for the new `5.0.x` and newer releases? |
| 122 | + |
| 123 | +The applicable maintenance and support policy is documented in the `SUPPORT.md` file of the |
| 124 | +[`aws/jsii-compiler`][compiler-support] and [`aws/jsii-rosetta`][rosetta-support] repositories. The main aspects of the |
| 125 | +new support policy are: |
| 126 | + |
| 127 | +* Only the latest release line is deemed **Current**, and receives new features, bug fixes, and security updates; |
| 128 | +* Once a release stops being **Current**, it moves into **Maintenance**, where it continues receiving bug fixes and |
| 129 | + security updates, but no new features will be added; |
| 130 | +* After six (6) months in **Maintenance**, a release line moves to **End-of-Support**, and is no longer maintained. |
| 131 | + |
| 132 | +[compiler-support]: https://github.com/aws/jsii-compiler/blob/v5.0.0/SUPPORT.md |
| 133 | +[rosetta-support]: https://github.com/aws/jsii-rosetta/blob/v5.0.0/SUPPORT.md |
| 134 | + |
| 135 | +### What happens if I continue using releases after they reach End-of-Support? |
| 136 | + |
| 137 | +Once End-of-Support is declared for the releases, we will no longer be able to provide support, bug fixes, or security |
| 138 | +updates for these releases. You may elect to continue to use them at your discretion (published releases will remain |
| 139 | +available to download from the [npmjs.com](http://npmjs.com/) package registry indefinitely). You should be aware that, |
| 140 | +although there is no plan to introduce non-backwards compatible features at this stage, it is possible that some of your |
| 141 | +library’s dependencies may stop being compatible with `1.x` releases of the compiler in the future, and your library’s |
| 142 | +dependents may at some point no longer be able to consume `1.x` compiler output artifacts. |
0 commit comments