ember-cli 6.6.0-beta.1 → 6.7.0-alpha.2

package/CHANGELOG.md

@@ -1,5 +1,45 @@
 # ember-cli Changelog
 
+## Release (2025-06-30)
+
+* @ember-tooling/classic-build-addon-blueprint 6.7.0-alpha.2 (patch)
+* @ember-tooling/classic-build-app-blueprint 6.7.0-alpha.2 (patch)
+* @ember-tooling/blueprint-blueprint 0.0.1 (patch)
+* @ember-tooling/blueprint-model 0.0.1 (patch)
+* ember-cli 6.7.0-alpha.2 (patch)
+
+#### :house: Internal
+* Other
+  * [#10735](https://github.com/ember-cli/ember-cli/pull/10735) remove unnecessary project override ([@mansona](https://github.com/mansona))
+* `@ember-tooling/classic-build-addon-blueprint`, `@ember-tooling/classic-build-app-blueprint`, `@ember-tooling/blueprint-blueprint`, `@ember-tooling/blueprint-model`
+  * [#10736](https://github.com/ember-cli/ember-cli/pull/10736) update all sub-packages to have the @ember-tooling prefix ([@mansona](https://github.com/mansona))
+  * [#10671](https://github.com/ember-cli/ember-cli/pull/10671) Implement the built in app, addon, and blueprint blueprints by package lookup ([@mansona](https://github.com/mansona))
+
+#### Committers: 1
+- Chris Manson ([@mansona](https://github.com/mansona))
+
+## Release (2025-06-16)
+
+* ember-cli 6.7.0-alpha.1 (minor)
+
+#### :rocket: Enhancement
+* `ember-cli`
+  * [#10705](https://github.com/ember-cli/ember-cli/pull/10705) add `--strict` flag for new app and addon generation ([@mansona](https://github.com/mansona))
+
+#### :memo: Documentation
+* `ember-cli`
+  * [#10724](https://github.com/ember-cli/ember-cli/pull/10724) Update RELEASE.md to fully document new release-plan setup ([@mansona](https://github.com/mansona))
+
+#### :house: Internal
+* `ember-cli`
+  * [#10731](https://github.com/ember-cli/ember-cli/pull/10731) Prepare Alpha 6.7.0 ([@mansona](https://github.com/mansona))
+  * [#10728](https://github.com/ember-cli/ember-cli/pull/10728) Prepare Beta 6.6.0 ([@mansona](https://github.com/mansona))
+  * [#10726](https://github.com/ember-cli/ember-cli/pull/10726) use patched github-changelog for properly rolling up beta changelog ([@mansona](https://github.com/mansona))
+  * [#10717](https://github.com/ember-cli/ember-cli/pull/10717) pass --publish-branch to release-plan publish ([@mansona](https://github.com/mansona))
+
+#### Committers: 1
+- Chris Manson ([@mansona](https://github.com/mansona))
+
 ## Release (2025-06-16)
 
 * ember-cli 6.6.0-beta.1 (minor)

package/RELEASE.md

@@ -1,3 +1,156 @@
 # Release Process
 
-This document has been updated and is being actively managed on the default branch of this repo. Please refer to the version on the default branch to follow the release process: https://github.com/ember-cli/ember-cli/blob/master/RELEASE.md
+`ember-cli` follows the same channel based release process that Ember does:
+
+* `release` - This branch represents the `latest` dist-tag on NPM
+* `beta` - This branch represents the `beta` dist-tag on NPM
+* `master` - The branch represents the `alpha` dist-tag on NPM
+
+Most changes should be made as a PR that targets the `master` branch and then makes their way through `beta` and `release` over the course of 12 weeks as part of the Ember release train. Generally speaking we do not backport functional changes to `beta` or `release` but we can if needs be.
+
+This release process is managed by [release-plan](https://github.com/embroider-build/release-plan) which means that all changes should be made as a pull request to make sure it is captured in the changelog.
+
+## Release process overview
+
+During the release week each of the versions are effectively "promoted" i.e. the current `beta` version is released as `latest`, the current `alpha` version is released as `beta` and a **new** `alpha` version is created. This requires PRs to each of the active branches to update ember-source (and potentially ember-data) versions. Each of those PRs that update dependencies should be marked as `enhancement` if we are releasing a minor version.
+
+The release process during release week should look like this:
+
+- Do an intial stable release from the `release` branch
+- Merge `release` into `beta`
+- Do a `beta` release
+- Merge `beta` into `master`
+- Do an `alpha` release
+
+
+### Initial Stable Release from the `release` branch
+
+- fetch latest from origin `git fetch`
+- create a new branch to do the release e.g. `git checkout --no-track -b release-plan-6-4 origin/release`
+  - note: branches named like `release-6-4` are used to manage LTS patch releases so we don't want to create a branch with that name at this time
+- Merge `origin/beta` into the release branch
+  - `git merge origin/beta --no-ff`
+  - **make sure to not update the .release-plan file** this should only ever be changed by the release-plan github scripts
+  - make sure to not update the version in the package.json during this step, this will be release-plan's job
+- Update blueprint dependencies to latest
+
+```
+node ./dev/update-blueprint-dependencies.js --ember-source=latest --ember-data=latest
+```
+
+- commit this update `git commit -am "update blueprint dependencies to latest"`
+- push and open a PR targeting `release`
+- mark this PR as an `enhancement` if it is a minor release
+- check that everything is ok
+- merge branch
+- check that the `Prepare Release` PR has been correctly opened by `release-plan`
+- Merge the `Prepare Release` branch when you are ready to release
+- Check the `Release Stable` GitHub action to make sure the release succeeded
+
+### Beta release from the `beta` branch
+
+- fetch latest from origin `git fetch`
+- create a new branch to merge `release` into `beta` e.g. `git checkout --no-track -b merge-release origin/beta`
+- merge release into this new branch e.g. `git merge origin/release --no-ff`
+  - **make sure to not update the .release-plan file** this should only ever be changed by the release-plan github scripts
+- merge master into this new branch too e.g. `git merge origin/master --no-ff`
+  - **make sure to not update the .release-plan file** this should only ever be changed by the release-plan github scripts
+  - update the alpha version in package.json to be a beta i.e. if the incoming merge is `"version": "6.6.0-alpha.3",` update it to `"version": "6.6.0-beta.0",`
+- Update blueprint dependencies to beta
+
+```
+node ./dev/update-blueprint-dependencies.js --ember-source=beta --ember-data=beta
+```
+
+- commit this update `git commit -am "update blueprint dependencies to beta"`
+- push and open a PR targeting `beta`
+- mark this PR as an `enchancement` if the next beta is a minor release
+- check that everything is ok i.e. CI passes
+- merge the `merge-release` branch into `beta` in GitHub
+- check that the `Prepare Beta Release` PR has been correctly opened by `release-plan`
+  - note: the release-plan config will automatically make this version a pre-release
+- Merge the `Prepare Beta Release` when you are ready to release the next beta version
+- Check the `Release Beta` GitHub action to make sure the release succeeded
+
+
+### Alpha release from the `master` branch
+
+- fetch latest from origin `git fetch`
+- create a new branch to merge `beta` into `master` e.g. `git checkout --no-track -b merge-beta origin/master`
+- merge beta into this new branch e.g. `git merge origin/beta --no-ff`
+  - **make sure to not update the .release-plan file** this should only ever be changed by the release-plan github scripts
+- manually update the version in pacakge.json to be the next alpha.
+  - e.g. if the current alpha is `"version": "6.6.0-alpha.3",` update it to be `"version": "6.7.0-alpha.0",`
+- commit this change to the version in package.json: `git commit -am "update to the next alpha version"`
+- Update blueprint dependencies to alpha
+
+```
+node ./dev/update-blueprint-dependencies.js --ember-source=alpha --ember-data=canary
+```
+
+- commit this update `git commit -am "update blueprint dependencies to alpha"`
+- push and open a PR targeting `master`
+- mark this PR as an `enchancement` if the next alpha is a minor release
+- check that everything is ok i.e. CI passes
+- merge the `merge-beta` branch into `master` in GitHub
+- check that the `Prepare Alpha Release` PR has been correctly opened by `release-plan`
+- Merge the `Prepare Alpha Release` when you are ready to release the next alpha version
+- Check the `Release Alpha` GitHub action to make sure the release succeeded
+
+
+## Changelog updates
+
+`release-plan` is designed to automatically generate a Changelog that includes the titles of every PR that was merged since the last release. As we would like to make use of this auto-generated Changelog we need to make sure that PRs are named correctly and the Changelog included in the "Prepare Release" PRs are what we were expecting.
+
+If you want to change the content of the Changelog then you should update the PR titles you want to update and re-run the `Prepare Release` CI job for that branch. If there are PRs that you would prefer to exclude from the changelog (such as the `merge-beta` or `merge-release` PRs) then you can add the `ignore` label to the PR and they will be removed from the changelog.
+
+## Patch Releases
+
+Now that we're using release-plan for all releases, patch releases have become super easy! Every time you merge a PR to any branch that is being released with `release-plan` a new `Prepare Release` PR will be created. When you merge this `Prepare Release` branch it will automatically release the new Patch version.
+
+
+## Post-release Automation
+
+There is a GitHub Actions workflow, https://github.com/ember-cli/ember-cli/actions/workflows/sync-output-repos.yml that pushes various invocations of the blueprint generator to "output repos".
+After release, make sure that all the jobs are "green" / succeeded.
+
+<details><summary>What to check afterwards</summary>
+
+- Apps: https://github.com/ember-cli/ember-app-output
+- Addons: https://github.com/ember-cli/ember-addon-output
+
+Both of these have a git-tag per release version
+
+### Online Editors
+
+Multiple editors could be supported, but right now, we only "customize" for stackblitz.
+
+https://github.com/ember-cli/editor-output/
+- [a branch for each scenario + release version](https://github.com/ember-cli/editor-output/branches/active)
+  - `${editorName}-{addon,app}-output{-'typescript'?}{-version}`
+  - and the "latest release" (non beta) will not have a version at the end
+  - This includes [app, addon] X [javascript, typescript]
+
+#### StackBlitz
+
+To make sure StackBlitz runs in their supported browsers (Chrome and FireFox, as of 2023-08-15)
+
+- App + JS: https://stackblitz.com/github/ember-cli/editor-output/tree/stackblitz-app-output
+- App + TS: https://stackblitz.com/github/ember-cli/editor-output/tree/stackblitz-app-output-typescript
+- Addon + JS: https://stackblitz.com/github/ember-cli/editor-output/tree/stackblitz-addon-output
+- Addon + TS: https://stackblitz.com/github/ember-cli/editor-output/tree/stackblitz-addon-output-typescript
+
+The App + JS, and App + TS are linked from Stackblitz's frontend templates UI: https://stackblitz.com/?starters=frontend
+
+</details>
+
+<details><summary>if problems arise</summary>
+
+Script for updating addon/app repos: https://github.com/ember-cli/ember-cli/blob/master/dev/update-output-repos.js
+Script for updating editors: https://github.com/ember-cli/ember-cli/blob/master/dev/update-editor-output-repos.js
+
+Customizations on top of the default blueprint(s) are found here: https://github.com/ember-cli/ember-cli/tree/master/dev/online-editors/stackblitz
+The intent for these customizations is to either be very light, or not needed at all.
+If an online editor breaks with our default blueprint, then it's most likely that _we_ have a bug (or something _very goofy_).
+
+</details>