Add the logic for the release of the unstable modules #15591

skinny85 · 2021-07-15T18:42:42Z

We need to:

Create the bump logic in the cdk-release tool for unstable modules. The exact logic of the version bumping depends on the questions answered in Finalize the versions of the unstable modules in V2 #15581.

The probable implementation is creating a version.json file in each directory of the generated unstable package with the current version, and bumping it if already exists.
Modify the build of the alpha packages to take the version from the above mentioned file.
Change the align-versions script to use the version from the above mentioned file to change the actual versions in package.json to the stated version.
Add logic to the cdk-release tool that generates the individual Changelogs, and possibly integrates them with the master V2 Changelog.

The text was updated successfully, but these errors were encountered:

As part of the project to release our alpha modules as independent modules, this change extends our `cdk-release` tool to support tracking and bumping two versions: the primary, stable version, and an additional, optional alpha version. If the local `version.vX.json` file has an `alphaVersion` property, this version will be bumped alongside the main (stable) version. If the main version is also a prerelease, then the alphaVersion is simply incremented (e.g., `2.0.0-alpha.0` -> `2.0.0-alpha.1`); if the main version is stable, the alpha is incremented to match (e.g., the `2.1.0` release will get an alpha of `2.1.0-alpha.0`). If no `alphaVersion` is present, it is simply ignored. This is still only part of the work to release the alpha modules. Remaining: - Create the indepedent module CHANGELOGs, and aggregate into the main CHANGELOG - Change the `align-versions` script to read and apply the alphaVersion if the module is an alpha module. - Create the first alpha version in the v2-main branch. *Implementation details:* I was frustrated by the generic 'Updater' and 'UpdaterModule' pattern that I needed to work around, so I decided to just simplify by removing the generic capabilities that we're not using. This involved deleting a lot of code that wasn't doing much. Lots of refactoring ensured. Similarly, there simply weren't nearly enough tests in this module yet; I added at least a few more to improve coverage in anticipation of the next tasks (which will require even more tests). My apologies to the reviewer(s) for the muddled diff, but I strongly believe these simplifications will make it easier to maintain `cdk-release` going forward. related #15591

njlynch · 2021-08-13T15:05:57Z

#16043 tackles the first part of this task: the bump logic itself. Given the decisions made in the versioning discussion (#15581 ), this was actually rather straightforward; simply add a new alpha version to the main version.vN.json file and bump alongside the primary/stable version.

I'm tackling the fourth item (changelogs) next.

As part of the project to release our alpha modules as independent modules, this change extends our `cdk-release` tool to support tracking and bumping two versions: the primary, stable version, and an additional, optional alpha version. If the local `version.vX.json` file has an `alphaVersion` property, this version will be bumped alongside the main (stable) version. If the main version is also a prerelease, then the alphaVersion is simply incremented (e.g., `2.0.0-alpha.0` -> `2.0.0-alpha.1`); if the main version is stable, the alpha is incremented to match (e.g., the `2.1.0` release will get an alpha of `2.1.0-alpha.0`). If no `alphaVersion` is present, it is simply ignored. This is still only part of the work to release the alpha modules. Remaining: - Create the indepedent module CHANGELOGs, and aggregate into the main CHANGELOG - Change the `align-versions` script to read and apply the alphaVersion if the module is an alpha module. - Create the first alpha version in the v2-main branch. *Implementation details:* I was frustrated by the generic 'Updater' and 'UpdaterModule' pattern that I needed to work around, so I decided to just simplify by removing the generic capabilities that we're not using. This involved deleting a lot of code that wasn't doing much. Lots of refactoring ensured. Similarly, there simply weren't nearly enough tests in this module yet; I added at least a few more to improve coverage in anticipation of the next tasks (which will require even more tests). My apologies to the reviewer(s) for the muddled diff, but I strongly believe these simplifications will make it easier to maintain `cdk-release` going forward. related #15591 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

This is part of the continued work to release the experimental modules as independent alpha modules. This change introduces a new mode for handling changes in the changelog: in this new mode, all experimental features are still stripped from the main changelog (as they are currently for v2), but individual changelogs are also created for each experimental package to show the changes specific to those packages. I _believe_ the final behavior should be that the experimental changes are also included in the main changelog, under a new heading, but decided to save that for the next rev, as there's still some ambiguity about the best customer experience, and what's most feasible given conventional-changelog. related #15591

As part of the project to release our alpha modules as independent modules, this change extends our `cdk-release` tool to support tracking and bumping two versions: the primary, stable version, and an additional, optional alpha version. If the local `version.vX.json` file has an `alphaVersion` property, this version will be bumped alongside the main (stable) version. If the main version is also a prerelease, then the alphaVersion is simply incremented (e.g., `2.0.0-alpha.0` -> `2.0.0-alpha.1`); if the main version is stable, the alpha is incremented to match (e.g., the `2.1.0` release will get an alpha of `2.1.0-alpha.0`). If no `alphaVersion` is present, it is simply ignored. This is still only part of the work to release the alpha modules. Remaining: - Create the indepedent module CHANGELOGs, and aggregate into the main CHANGELOG - Change the `align-versions` script to read and apply the alphaVersion if the module is an alpha module. - Create the first alpha version in the v2-main branch. *Implementation details:* I was frustrated by the generic 'Updater' and 'UpdaterModule' pattern that I needed to work around, so I decided to just simplify by removing the generic capabilities that we're not using. This involved deleting a lot of code that wasn't doing much. Lots of refactoring ensured. Similarly, there simply weren't nearly enough tests in this module yet; I added at least a few more to improve coverage in anticipation of the next tasks (which will require even more tests). My apologies to the reviewer(s) for the muddled diff, but I strongly believe these simplifications will make it easier to maintain `cdk-release` going forward. related aws#15591 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

This is part of the continued work to release the experimental modules as independent alpha modules. This change introduces a new mode for handling changes in the changelog: in this new mode, all changes from alpha modules are still stripped from the main changelog (as they are currently for v2); those alpha module changes are now also written to a dedicated changelog (e.g., `CHANGELOG.v2.alpha.md`). related #15591 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

madeline-k · 2021-09-01T15:49:45Z

#16321 and #16322 address items 2 and 3.

This will be used by a change in `tools/individual-pkg-gen/copy-files-removing-deps.ts` on the `v2-main` branch, so that the `transform` step can correctly set the `version` key and the version for each dependency in each alpha module's `package.json` file. See #16322 for usage. Part of #15591 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…ckage.json files if present (#16322) This change sets the `version` key in each alpha module's `package.json` file to the alphaVersion that was created in this PR: #16043 And, also sets the version of each dependency on another alpha module to the same version. Depends on: #16321 Part of: #15591 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

This will be used by a change in `tools/individual-pkg-gen/copy-files-removing-deps.ts` on the `v2-main` branch, so that the `transform` step can correctly set the `version` key and the version for each dependency in each alpha module's `package.json` file. See aws#16322 for usage. Part of aws#15591 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

As part of the project to release our alpha modules as independent modules, this change extends our `cdk-release` tool to support tracking and bumping two versions: the primary, stable version, and an additional, optional alpha version. If the local `version.vX.json` file has an `alphaVersion` property, this version will be bumped alongside the main (stable) version. If the main version is also a prerelease, then the alphaVersion is simply incremented (e.g., `2.0.0-alpha.0` -> `2.0.0-alpha.1`); if the main version is stable, the alpha is incremented to match (e.g., the `2.1.0` release will get an alpha of `2.1.0-alpha.0`). If no `alphaVersion` is present, it is simply ignored. This is still only part of the work to release the alpha modules. Remaining: - Create the indepedent module CHANGELOGs, and aggregate into the main CHANGELOG - Change the `align-versions` script to read and apply the alphaVersion if the module is an alpha module. - Create the first alpha version in the v2-main branch. *Implementation details:* I was frustrated by the generic 'Updater' and 'UpdaterModule' pattern that I needed to work around, so I decided to just simplify by removing the generic capabilities that we're not using. This involved deleting a lot of code that wasn't doing much. Lots of refactoring ensured. Similarly, there simply weren't nearly enough tests in this module yet; I added at least a few more to improve coverage in anticipation of the next tasks (which will require even more tests). My apologies to the reviewer(s) for the muddled diff, but I strongly believe these simplifications will make it easier to maintain `cdk-release` going forward. related aws#15591 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

This is part of the continued work to release the experimental modules as independent alpha modules. This change introduces a new mode for handling changes in the changelog: in this new mode, all changes from alpha modules are still stripped from the main changelog (as they are currently for v2); those alpha module changes are now also written to a dedicated changelog (e.g., `CHANGELOG.v2.alpha.md`). related aws#15591 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

This will be used by a change in `tools/individual-pkg-gen/copy-files-removing-deps.ts` on the `v2-main` branch, so that the `transform` step can correctly set the `version` key and the version for each dependency in each alpha module's `package.json` file. See aws#16322 for usage. Part of aws#15591 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

As part of the project to release our alpha modules as independent modules, this change extends our `cdk-release` tool to support tracking and bumping two versions: the primary, stable version, and an additional, optional alpha version. If the local `version.vX.json` file has an `alphaVersion` property, this version will be bumped alongside the main (stable) version. If the main version is also a prerelease, then the alphaVersion is simply incremented (e.g., `2.0.0-alpha.0` -> `2.0.0-alpha.1`); if the main version is stable, the alpha is incremented to match (e.g., the `2.1.0` release will get an alpha of `2.1.0-alpha.0`). If no `alphaVersion` is present, it is simply ignored. This is still only part of the work to release the alpha modules. Remaining: - Create the indepedent module CHANGELOGs, and aggregate into the main CHANGELOG - Change the `align-versions` script to read and apply the alphaVersion if the module is an alpha module. - Create the first alpha version in the v2-main branch. *Implementation details:* I was frustrated by the generic 'Updater' and 'UpdaterModule' pattern that I needed to work around, so I decided to just simplify by removing the generic capabilities that we're not using. This involved deleting a lot of code that wasn't doing much. Lots of refactoring ensured. Similarly, there simply weren't nearly enough tests in this module yet; I added at least a few more to improve coverage in anticipation of the next tasks (which will require even more tests). My apologies to the reviewer(s) for the muddled diff, but I strongly believe these simplifications will make it easier to maintain `cdk-release` going forward. related aws#15591 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

This is part of the continued work to release the experimental modules as independent alpha modules. This change introduces a new mode for handling changes in the changelog: in this new mode, all changes from alpha modules are still stripped from the main changelog (as they are currently for v2); those alpha module changes are now also written to a dedicated changelog (e.g., `CHANGELOG.v2.alpha.md`). related aws#15591 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

This will be used by a change in `tools/individual-pkg-gen/copy-files-removing-deps.ts` on the `v2-main` branch, so that the `transform` step can correctly set the `version` key and the version for each dependency in each alpha module's `package.json` file. See aws#16322 for usage. Part of aws#15591 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

github-actions · 2021-09-09T09:27:26Z

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

…ckage.json files if present (aws#16322) This change sets the `version` key in each alpha module's `package.json` file to the alphaVersion that was created in this PR: aws#16043 And, also sets the version of each dependency on another alpha module to the same version. Depends on: aws#16321 Part of: aws#15591 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…ckage.json files if present (#16965) This change was already approved and merged in: #16322. It somehow got removed from the `v2-main` branch since originally being merged. This PR is just a cherry-pick of the original commit. --- This change sets the `version` key in each alpha module's `package.json` file to the alphaVersion that was created in this PR: #16043 And, also sets the version of each dependency on another alpha module to the same version. Depends on: #16321 Part of: #15591 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…ckage.json files if present (aws#16965) This change was already approved and merged in: aws#16322. It somehow got removed from the `v2-main` branch since originally being merged. This PR is just a cherry-pick of the original commit. --- This change sets the `version` key in each alpha module's `package.json` file to the alphaVersion that was created in this PR: aws#16043 And, also sets the version of each dependency on another alpha module to the same version. Depends on: aws#16321 Part of: aws#15591 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

skinny85 changed the title ~~Perform a release of the unstable modules~~ Perform the actual release of the unstable modules Jul 15, 2021

skinny85 added aws-cdk-lib Related to the aws-cdk-lib package effort/large Large work item – several weeks of effort feature-request A feature should be added or improved. p1 labels Jul 15, 2021

skinny85 changed the title ~~Perform the actual release of the unstable modules~~ Add the logic for the release of the unstable modules Jul 15, 2021

njlynch self-assigned this Aug 11, 2021

njlynch mentioned this issue Aug 13, 2021

chore(cdk-release): track and bump separate alpha version #16043

Merged

njlynch mentioned this issue Aug 23, 2021

chore(cdk-release): support separate alpha Changelog #16182

Merged

This was referenced Sep 1, 2021

chore(resolve-version): export the alphaVersion #16321

Merged

chore(individual-pkg-gen): set the alpha version in alpha module's package.json files if present #16322

Merged

njlynch closed this as completed Sep 9, 2021

njlynch mentioned this issue Sep 9, 2021

[CDKv2GA] Enable publishing of alpha modules #16432

Closed

madeline-k mentioned this issue Oct 13, 2021

chore(individual-pkg-gen): set the alpha version in alpha module's package.json files if present #16965

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add the logic for the release of the unstable modules #15591

Add the logic for the release of the unstable modules #15591

skinny85 commented Jul 15, 2021 •

edited by njlynch

Loading

njlynch commented Aug 13, 2021

madeline-k commented Sep 1, 2021

github-actions bot commented Sep 9, 2021

Add the logic for the release of the unstable modules #15591

Add the logic for the release of the unstable modules #15591

Comments

skinny85 commented Jul 15, 2021 • edited by njlynch Loading

njlynch commented Aug 13, 2021

madeline-k commented Sep 1, 2021

github-actions bot commented Sep 9, 2021

⚠️COMMENT VISIBILITY WARNING⚠️

skinny85 commented Jul 15, 2021 •

edited by njlynch

Loading