From 73145baaafbc01a694758a4ace1e459ebd285c14 Mon Sep 17 00:00:00 2001 From: Edward Faulkner Date: Fri, 20 Sep 2024 09:00:17 -0400 Subject: [PATCH 1/4] Update tagging strategy This is preparation to make it possible to have more than one published package living in this monorepo. It changes the tagging strategy so that releases of ember-source should be tagged like `v6.0.0-ember-source` instead of `v6.0.0`. --- .github/workflows/alpha-releases.yml | 2 +- .github/workflows/ci.yml | 4 ++-- broccoli/build-info.js | 4 +++- tests/node/build-info-test.js | 8 ++++++++ 4 files changed, 14 insertions(+), 4 deletions(-) diff --git a/.github/workflows/alpha-releases.yml b/.github/workflows/alpha-releases.yml index 0a3bd66b6c5..bc23c28621f 100644 --- a/.github/workflows/alpha-releases.yml +++ b/.github/workflows/alpha-releases.yml @@ -52,7 +52,7 @@ jobs: NODE_AUTH_TOKEN: ${{ secrets.NPM_AUTH_TOKEN }} - name: push tag # Push in a way that will NOT trigger other workflows - run: git push origin v${{env.NEXT_ALPHA}} + run: git push origin v${{env.NEXT_ALPHA}}-ember-source notify: name: Notify Discord diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 208e5f263cb..035aee74af8 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -126,7 +126,7 @@ jobs: run: pnpm vite build --mode=development - name: Set BrowserStack Local Identifier - if: startsWith(github.ref, 'refs/tags/v') + if: startsWith(github.ref, 'refs/tags/v') && endsWith(github.ref, '-ember-source') run: | BROWSERSTACK_LOCAL_IDENTIFIER="$GITHUB_RUN_ID-$GITHUB_RUN_ATTEMPT" echo "BROWSERSTACK_LOCAL_IDENTIFIER=$BROWSERSTACK_LOCAL_IDENTIFIER" >> $GITHUB_ENV @@ -210,7 +210,7 @@ jobs: blueprint-test, browser-test, ] - if: startsWith(github.ref, 'refs/tags/v') + if: startsWith(github.ref, 'refs/tags/v') && endsWith(github.ref, '-ember-source') steps: - uses: actions/checkout@v4 - uses: ./.github/actions/setup diff --git a/broccoli/build-info.js b/broccoli/build-info.js index c0eaf0869b2..1b4c5df4f45 100644 --- a/broccoli/build-info.js +++ b/broccoli/build-info.js @@ -125,7 +125,9 @@ function readPackageVersion(root) { * @param {string} tag */ function parseTagVersion(tag) { - return tag && semver.parse(tag).version; + if (tag) { + return semver.parse(tag.replace(/-ember-source$/, '')).version; + } } /** diff --git a/tests/node/build-info-test.js b/tests/node/build-info-test.js index 830eca4f996..f25bbdef90a 100644 --- a/tests/node/build-info-test.js +++ b/tests/node/build-info-test.js @@ -48,6 +48,14 @@ QUnit.module('parseTagVersion', () => { tag: 'v3.1.1-beta.2', expected: '3.1.1-beta.2', }, + { + tag: 'v3.4.4-ember-source', + expected: '3.4.4', + }, + { + tag: 'v3.1.1-beta.2-ember-source', + expected: '3.1.1-beta.2', + }, ].forEach(({ tag, expected }) => { QUnit.test(JSON.stringify(tag), function (assert) { assert.equal(parseTagVersion(tag), expected); From aa585a682d0caa0370d808133d54933269b3eba5 Mon Sep 17 00:00:00 2001 From: Edward Faulkner Date: Fri, 20 Sep 2024 11:48:51 -0400 Subject: [PATCH 2/4] updating release docs --- RELEASE.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/RELEASE.md b/RELEASE.md index 4639eadf793..3cbe6493a25 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -33,7 +33,7 @@ 1. otherwise, start over 1. Update `package.json` and `VERSION` file to use new version number 1. git add/commit -m "Release v2.5.0-beta.2." -1. `git tag v2.5.0-beta.2` +1. `git tag v2.5.0-beta.2-ember-source` 1. `git push origin v2.5.0-beta.2`, and `let ciTag = kick off a CI build` (to produce the assets) 1. `git push origin beta` 1. `git checkout beta` @@ -90,7 +90,7 @@ Starting point: [https://gist.github.com/rwjblue/fb945e55c70d698d4074](https://g 1. Seems easy to automate fixing this. Replace reading `VERSION` with reading `package.json` so you only have to change it in one place 1. Commit `package.json`/`version` tags 1. Add commit message: "Release v2.4.0" -1. `git tag v2.4.0` +1. `git tag v2.4.0-ember-source` ### Release @@ -143,6 +143,6 @@ end #### Tag & Release 1. Update `package.json` and `VERSION` file to use new version number -1. `git tag v2.5.0-beta.1` +1. `git tag v2.5.0-beta.1-ember-source` 1. `git push origin v2.5.0-beta.1` 1. `git push -f origin beta:beta` From 614b3c502df2271b996d55bd8c5dc335d6368929 Mon Sep 17 00:00:00 2001 From: Katie Gengler Date: Fri, 20 Sep 2024 12:22:21 -0400 Subject: [PATCH 3/4] Update RELEASE.md, including the change to tag names --- RELEASE.md | 383 +++++++++++++++++++++++++++++++++-------------------- 1 file changed, 238 insertions(+), 145 deletions(-) diff --git a/RELEASE.md b/RELEASE.md index 3cbe6493a25..2e630f3fe43 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -1,148 +1,241 @@ # Ember.js Releases -## Concepts - -* 6-week release cycle - * weekly beta -* Channels - * Release (stable) - * Beta - * Canary -* SemVer - * Patch - * Minor (point) - * Major - ---- - -## Ember Notes on Point Releases (Not Release Notes) - -1. Check out `beta` branch and `git pull` -1. Make sure any main commits that are conceptually `[{BUGFIX,DOC} {beta,release}]` are cherry-picked. -1. `git push origin beta`, and `let ciBranch = kick off a CI build` -1. `PRIOR_VERSION=v2.5.0-beta.1 ./bin/changelog.js | uniq | pbcopy` -1. Open `CHANGELOG.md`, paste in the results of the previous script, and clean it up for human-readability. - 1. e.g. [BUGFIX beta] -> [BUGFIX], [DEPRECATE beta] -> [DEPRECATE], ... - 1. Revert [BUGFIX ...] -> [BUGFIX] Revert ... - 1. rm [DOC] (usually) - 1. rm other trivial things -1. Backport CHANGELOG to main -1. `await ciBranch` - 1. if CI succeeds, process - 1. if CI fails and it's a fix that doesn't need to be on main (e.g. linting or merge conflicts accidentally checked in), fix and retry. - 1. otherwise, start over -1. Update `package.json` and `VERSION` file to use new version number -1. git add/commit -m "Release v2.5.0-beta.2." -1. `git tag v2.5.0-beta.2-ember-source` -1. `git push origin v2.5.0-beta.2`, and `let ciTag = kick off a CI build` (to produce the assets) -1. `git push origin beta` +See [Ember.js Releases](https://emberjs.com/releases/) for an overview of how Ember.js releases work. + +Ember.js consists of many packages. A release of `Ember.js` is considered complete upon the release blog post on [the Ember blog](https://blog.emberjs.com/tag/release). + +This document is intended for maintainers of Ember.js. It describes the process for creating releases. + +## ember-source + +`ember-source` follows the Ember.js [release train/cycle](https://blog.emberjs.com/new-ember-release-process/). There is a stable release roughly every 6 weeks (every 4 versions excluding `x.0`) and a major release after every `x.12` release. New deprecations targeting the next major are not permitted to land after the `x.10` release. All public API changes should have an RFC and all features should behind feature flags. Features should not be enabled by default until the RFC has had a successful the [Ready for Release](https://github.com/emberjs/rfcs#ready-for-release) Stage. + +Features, bugfixes, deprecations and other PRs are merged primarily to the `main` branch. +These changes should be tagged according to what they are and whether they should be cherry-picked back to a beta, stable, or LTS release, see [Commit Tagging](https://github.com/emberjs/ember.js/blob/main/CONTRIBUTING.md#commit-tagging) in the CONTRIBUTING.md. These tags can also be in PR titles (as they are easier to edit after-the-fact than commit messages). + +Changes to `main` are released on every commit to `s3` as `canary`. +Weekly, changes on `main` are released as `alpha` on `npm`. + +At least weekly, a contributor looks for changes from `main` that are tagged (and appropriate to be backported) to `beta` and creates a new `beta` release if there are changes. + +In a beta cycle, there can be as few as 1 beta release or theoretically as many as needed, depending on the changes that land. + +After six weeks, the beta is "promoted" to release by a contributor creating a new stable release. When the stable release is published, the prior release may be promoted to LTS, if is a successful candidate. + +Generally changes should land on main. If a change needs to be backported to LTS, for example, it should be backported to beta to "settle" for a bit before being backported to release an the LTS. +Rarely, a change is needed on an older version but not needed on main or newer versions. In those cases, the PR should target the branch. + +### Creating a point release + +1. Look for any PRs targeting release that have not been merged. Consider if they are ready to be merged, and if so, ensure the changes are also on `main` and `beta` if they are needed in those versions. Generally changes should be cherry-picked back to `release` so that they are not accidentally orphaned on older versions and so that they can be tested on `beta` and `main` before a point release. +1. In `ember.js` repo, on main branch, `git pull` +1. `git checkout release` +1. `git pull` +1. Look for any unreleased changes on `release` -- take note so you know what to expect in the CHANGELOG generation. +1. Cherry-pick (using `git cherry-pick -x`) anything tagged `release` that was merged to main since the last release. To do this, look at merged PRs to find commits. The commit history isn't a good way to find these because it sorts by date, and some commits can be on old PRs that were finally merged. You may have to fix any conflicts. If this is beyond you, you can ask the original contributor to make a pull request to `release`. +1. `git push` to let CI run. You must push changes before running the CHANGELOG generation as it uses the GitHub API to find PRs. +1. Generate Changelog: + ```bash + HEAD=release PRIOR_VERSION=v5.10.1-ember-source ./bin/changelog.js | uniq | pbcopy + ``` + +1. Put the results in `CHANGELOG.md` under a heading for the new point release. Clean up the changelog, see [Producing the CHANGELOG](#producing-the-changelog) for the details. +1. Commit with message: + ``` + Add v5.10.2 to CHANGELOG for `ember-source` + ``` + +1. Update `package.json` version to: + ``` + 5.10.2 + ``` + +1. Commit with message: + ``` + Release v5.10.2-ember-source + ``` + +1. Tag commit: + ```bash + git tag v5.10.2-ember-source + ``` + +1. Push tag: + ```bash + git push origin v5.10.2-ember-source + ``` + +1. Push changes `git push` +1. Cherry-pick changelog commit to `main` branch and to the `beta` branch. +1. Draft release on Github, see [Creating a Release on Github](#creating-a-release-on-github). +1. Wait for CI on the tag and check published to npm with `npm info ember-source`. + +#### LTS Point release + +Follow the above steps but begin with the `lts-5-8` branch (or whatever the LTS branch you are targeting is). +This branch may need to be created if it does not exist from the tag. +After release, if it is the latest LTS, tag as LTS with `npm dist-tag add ember-source@5.8.1 lts`. + +### Creating a (n-th) beta release + +1. In `ember.js` repo, on main branch, `git pull` 1. `git checkout beta` -1. `rm -rf dist && mkdir dist && cp ../components-ember/* dist/` -1. Go to [https://github.com/emberjs/ember.js/releases](https://github.com/emberjs/ember.js/releases) -1. Click on the most recent tag (2.5.0-beta.2), and then click "Edit" -1. Start with `### Changelog` and copy/paste the changelog into the box -1. Make the title `Ember 2.5.0-beta.2` and check "This is a pre-release" for betas -1. Update [builds page](https://github.com/ember-learn/builds/tree/master/app/fixtures/ember) -1. Deploy - ---- - -## Ember Notes on Release (Not Release Notes) - -Starting point: [https://gist.github.com/rwjblue/fb945e55c70d698d4074](https://gist.github.com/rwjblue/fb945e55c70d698d4074) - -## LTS Releases - -1. In Ember bower repo, `git co -b lts-2-4` , `git push origin` -1. In `bin/publish_to_s3.js` and `bin/bower_ember_build`, add relevant "lts-2-4" lines (see https://github.com/emberjs/ember.js/commit/618de4fa036ab33dc760343decd355ede7b822bb) -1. Follow usual stable point-release steps (release the LTS as `2.4.${++latest}`) - -## Stable Release - -### Review Commits - -1. Ensure that all commits that are tagged for release are in the release. -1. Review commits by hand since last beta was cut. -1. -1. You may run into trouble since commits are at canary, but `release` is from a branch 6 weeks ago -1. @rwjblue: I have a changelog generator script that correctly links commits to PRs - 1. It looks at all commits on beta branch, finds the original commit where that come from, and finds the originating PR -1. If I happen to run that tool again, it tells me that I have already run it so I don't accidentally run it twice -1. @rwjblue: I manually scan commits looking for "bugfix beta" and cherry-pick them into the beta branch (which is imminently becoming the `release` branch) - 1. Automating "look for bugfix beta commits since last beta release" seems like an easy win (@tomdale) - -### Build Changelog - -1. Push `beta` branch to get CI to run -1. Run `PRIOR_VERSION= ./bin/changelog.js | uniq | pbcopy` -1. Clean up commits in CHANGELOG - 1. e.g. [BUGFIX beta] -> [BUGFIX], [DEPRECATE beta] -> [DEPRECATE], ... - 1. Remove `[DOC]` changes (who cares) - 1. Improve formatting (you're now in a Markdown document, so wrap code in ``s. -1. Collapse all "beta" sections into final release - 1. E.g., commits from "beta.1", "beta.2", "beta.3" should just go under "2.4.0" or whatever -1. Commit CHANGELOG - -### Bump Version - -1. Edit `package.json` to correct version (2.4.0) -1. Edit `VERSION` file to correct value - 1. Seems easy to automate fixing this. Replace reading `VERSION` with reading `package.json` so you only have to change it in one place -1. Commit `package.json`/`version` tags -1. Add commit message: "Release v2.4.0" -1. `git tag v2.4.0-ember-source` - -### Release - -1. `git push origin v2.4.0` to push JUST the tag. This lets us run the tag first on CI, which does the correct deploy to S3, Bower, etc. -1. THEN wait for CI build to finish -1. Go to github and disable branch protection for the **release** branch -1. Backup the current release branch: `git push origin release:release-version` -1. To make this the current `release` branch: `git push -f origin beta:release` - 1. This promotes the `beta` branch on your machine (that has all of the release commits) the new `release` branch on `origin` -1. If you are paranoid like rojax, "freeze" this version of Ember in amber: `mv ember-beta ember-release-v2.4` -1. Go to github and enable branch protection for the **release** branch - -### Add Release on GitHub - -1. Go to GitHub and add a new release -1. Add title: `Ember 2.4` -1. Copy and paste CHANGELOG - -``` -# generate-api-docs.rb -require 'yaml' - -data = YAML.load_file("../components-ember/ember-docs.json") -data["project"]["sha"] = ENV['VERSION'] - -File.open("data/api.yml", "w") do |f| - YAML.dump(data, f) -end -``` - -## On to the Beta Release… - -1. Check out `main` branch and pull to get latest `canary` on your local machine -1. `nombom` and run those tests! -1. Branch locally to `beta` - 1. `git checkout -b beta` -1. Manually disable features - 1. Change everything in `packages/@ember/canary-features.ts`'s `DEFAULT_FEATURES` export from `null` to `false` to ensure they are stripped - 1. Any feature that has been GOed gets changed to true -1. Run `ember s -prod` -1. Run tests at `http://localhost:4200/tests/index.html` -1. Run production tests `http://localhost:4200/tests/index.html?dist=prod&prod=true` -1. Now we have to look at the commit just prior to branching 2.4.0.beta-1. Then find the commit after that to start the new branch at. - -### Changelog - -1. `PRIOR_VERSION=v2.4.0-beta.1^ HEAD=main ./bin/changelog.js | uniq | pbcopy` -1. Clean up changelog. Make sure the changelog from the stable release you just did is included. - -#### Tag & Release - -1. Update `package.json` and `VERSION` file to use new version number -1. `git tag v2.5.0-beta.1-ember-source` -1. `git push origin v2.5.0-beta.1` -1. `git push -f origin beta:beta` +1. `git pull` +1. Look for any unreleased changes on `beta` -- take note so you know what to expect in the CHANGELOG generation. +1. Cherry-pick (using `git cherry-pick -x`) anything tagged `beta` that was merged to main since the last beta. To do this, look at merged PRs to find commits. The commit history isn't a good way to find these because it sorts by date, and some commits can be on old PRs that were finally merged. You may have to fix any conflicts. If this is beyond you, you can ask the original contributor to make a pull request to `beta`. +1. `git push` to let CI run. You must push changes before running the CHANGELOG generation as it uses the GitHub API to find PRs. +1. Generate Changelog + ```bash + HEAD=beta PRIOR_VERSION=v5.12.0-beta.1-ember-source ./bin/changelog.js | uniq | pbcopy + ``` +1. Put the results in `CHANGELOG.md` under a heading for the new beta release. Clean up the changelog, see [Producing the CHANGELOG](#producing-the-changelog) for the details. +1. Commit with message: + ``` + Add v5.12.0-beta.2 to CHANGELOG for `ember-source` + ``` +1. Update `package.json` version to: + ``` + 5.12.0-beta.2 + ``` +1. Commit with message: + ``` + Release v5.12.0-beta.2-ember-source + ``` +1. Tag commit: + ```bash + git tag v5.12.0-beta.2-ember-source + ``` +1. Push tag: + ```bash + git push origin v5.12.0-beta.2-ember-source + ``` +1. Push changes to branch `git push` +1. Cherry-pick changelog commit to main branch. +1. Draft release on Github, see [Creating a Release on Github](#creating-a-release-on-github). +1. Wait for CI on the tag and check published to npm with `npm info ember-source`. + + +### Creating a stable release + +1. Look for any unreleased changes on `release`. If there are, consider whether there should first be a point release to the old stable version before creating a new stable release. +1. In `ember.js` repo, on main branch, `git pull`. +1. `git checkout beta`. (Note the branch! This is the release train). +1. `git pull`. +1. Cherry-pick (using `git cherry-pick -x`) anything tagged `release` that was merged to main since the last beta release. To do this, look at merged PRs to find commits. The commit history isn't a good way to find these because it sorts by date, and some commits can be on old PRs that were finally merged. You may have to fix any conflicts. If this is beyond you, you can ask the original contributor to make a pull request to `release`. +1. `git push` to let CI run. You must push changes before running the CHANGELOG generation as it uses the GitHub API to find PRs. +1. Generate Changelog. The `PRIOR_VERSION` should be the last beta release of the series. + ```bash + HEAD=beta PRIOR_VERSION=v5.12.0-beta.6-ember-source ./bin/changelog.js | uniq | pbcopy + ``` +1. Put the results in `CHANGELOG.md` under a heading for the new stable release. Combine the previous `beta` headings into one entry. Clean up the changelog, see [Producing the CHANGELOG](#producing-the-changelog) for the details. +1. Commit with message + ``` + Add v5.12.0 to CHANGELOG for `ember-source` + ``` +1. Update `package.json` version to: + ``` + 5.12.0 + ``` +1. Commit with message: + ``` + Release v5.12.0-ember-source + ``` +1. Tag commit: + ```bash + git tag v5.12.0-ember-source + ``` +1. Push tag: + ```bash + git push origin v5.12.0-ember-source + ``` +1. Make the `beta` branch into the `release` branch: + ```bash + git co -B release + ``` +1. Push the new `release` branch: + ```bash + git push -f origin release + ``` +1. Cherry-pick changelog commit to main branch. +1. Draft release on Github, see [Creating a Release on Github](#creating-a-release-on-github). +1. Wait for CI on the tag and check published to npm with `npm info ember-source`. +1. Consider whether to tag the previous version as LTS with `npm dist-tag add ember-source@5.8.0 lts`. A version is tagged LTS when the next stable version is released. LTS versions are roughly every 4 versions, excluding the `x.0` minor version. +1. Mark the release as complete in the Ember discord. +1. Create the new beta. + +### Creating a new beta (after a stable release) + +1. In `ember.js` repo, on main branch, `git pull`. +1. Make a new beta branch: + ```bash + git co -B beta + ``` +1. Toggle off any features that have not been explicitly toggled on in `packages/@ember/canary-features/index.ts`. +1. Find the `sha` of the last commit common to `main` and the old `beta` branch. This is typically the cherry-pick of the CHANGELOG entry. +1. Generate Changelog. The `PRIOR_VERSION` is that `sha`: + ```bash + HEAD=main PRIOR_VERSION=3daedddaafd638a4a6b12e0265df30255d1512e5 ./bin/changelog.js | uniq | pbcopy + ``` +1. Put the results in `CHANGELOG.md` under a heading for the new beta release. Clean up the changelog, see [Producing the CHANGELOG](#producing-the-changelog) for the details. +1. Commit with message: + ``` + Add v5.12.0-beta.1 to CHANGELOG for `ember-source` + ``` +1. Update `package.json` version to: + ``` + 5.12.0-beta.1 + ``` +1. Commit with message: + ``` + Release v5.12.0-beta.1-ember-source + ``` +1. Tag commit: + ```bash + git tag v5.12.0-beta.1-ember-source + ``` +1. Push tag: + ```bash + git push origin v5.12.0-beta.1-ember-source + ``` +1. Push changes to branch: + ```bash + git push -f origin beta + ``` +1. Cherry-pick changelog commit to main branch. +1. Update the main branch version to the next version in package.json: `6.0.0-alpha.1` with message `Post-relase version bump`. Remember that versions go to the next major after the `x.12` release per the [Major Version Process RFC](https://rfcs.emberjs.com/id/0830-evolving-embers-major-version-process/). +1. Draft release on Github, see [Creating a Release on Github](#creating-a-release-on-github). + +### Producing the CHANGELOG +[Producing the CHANGELOG]: #producing-the-changelog + +The CHANGELOG should make sense from the perspective of a user. Remove anything that is not user-facing. +The CHANGELOG entry is typically the PR title, but it can often be rewritten to be more user-friendly. +Also remove the `beta` and `release` tags from the PR titles. + +Title the CHANGELOG entry with the version and the date of the release in this format: `## v5.11.0 (August 15, 2023)`. + +1. Remove any `[DOC]` changes (usually) +1. Remove any entries for PRs that were in prior (by semver) releases +1. Remove any `[INTERNAL]` changes (not user-facing). Some changes may warrant staying in the CHANGELOG, but most do not. +1. `[CLEANUP]` entries may or may not be user-facing. This tag is typically used for removals of deprecated features. +1. Collapse multiple PRs that were for the same issue into a single entry: `- [#12345](https://example.org/emberjs/ember.js/pull/12345) / [#67890](https://example.org/emberjs/ember.js/pull/67890) [BUGFIX] Fix an exception thrown only on Tuesdays.` +1. Handle any `[FEATURE]` entries: + 1. If the feature is still behind a non-enabled feature flag, remove the entry. + 1. If the feature is now enabled by default, add an entry: + 1. Find the PRs that contributed to the feature. + 1. Link to the RFC that introduced the feature on the RFC website in the entry: `- [#20464](https://github.com/emberjs/ember.js/pull/20464) [FEATURE] Create public import for uniqueId helper per [RFC #659](https://rfcs.emberjs.com/id/0659-unique-id-helper).` +1. Change `[BUGFIX beta]` `[BUGFIX release]` `[BUGFIX stable]` to `[BUGFIX]` +1. Change `[DEPRECATION beta]` `[DEPRECATION release]` `[DEPRECATION stable]` to `[DEPRECATION]` +1. Handle any other PR or commit tags similarly. + +### Creating a Release on Github +[Creating a Release on Github]: #creating-a-release-on-github + +1. Go to the [Ember.js releases page](https://github.com/emberjs/ember.js/releases) +2. Click the "Draft a new release" button +3. Choose the tag of the release you just created +4. Title the release with the name of the tag `v5.11.0-ember-source` (or whatever the version is). +5. Add a header to the description of `### CHANGLEOG`. +6. Copy the CHANGELOG entry for the version below this header. +7. Check 'Pre-release' if this is not a stable release. +8. Choose `Set as the latest release` only if this is the latest stable release. Do not check this for the release of a point release on an older version. From e42dfbcfc93d4293e95ccfc6ecb02553a9907ae7 Mon Sep 17 00:00:00 2001 From: Edward Faulkner Date: Mon, 23 Sep 2024 14:19:11 -0400 Subject: [PATCH 4/4] Update RELEASE.md Co-authored-by: Katie Gengler --- RELEASE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RELEASE.md b/RELEASE.md index 2e630f3fe43..1c1e9fa01c6 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -8,7 +8,7 @@ This document is intended for maintainers of Ember.js. It describes the process ## ember-source -`ember-source` follows the Ember.js [release train/cycle](https://blog.emberjs.com/new-ember-release-process/). There is a stable release roughly every 6 weeks (every 4 versions excluding `x.0`) and a major release after every `x.12` release. New deprecations targeting the next major are not permitted to land after the `x.10` release. All public API changes should have an RFC and all features should behind feature flags. Features should not be enabled by default until the RFC has had a successful the [Ready for Release](https://github.com/emberjs/rfcs#ready-for-release) Stage. +`ember-source` follows the Ember.js [release train/cycle](https://blog.emberjs.com/new-ember-release-process/). There is a stable release roughly every 6 weeks (every 4 versions excluding `x.0` is an LTS candidate) and a major release after every `x.12` release. New deprecations targeting the next major are not permitted to land after the `x.10` release. All public API changes should have an RFC and all features should behind feature flags. Features should not be enabled by default until the RFC has had a successful the [Ready for Release](https://github.com/emberjs/rfcs#ready-for-release) Stage. Features, bugfixes, deprecations and other PRs are merged primarily to the `main` branch. These changes should be tagged according to what they are and whether they should be cherry-picked back to a beta, stable, or LTS release, see [Commit Tagging](https://github.com/emberjs/ember.js/blob/main/CONTRIBUTING.md#commit-tagging) in the CONTRIBUTING.md. These tags can also be in PR titles (as they are easier to edit after-the-fact than commit messages).