feat: automatic catch up from 5.11 to 6.1

guides/configuring-ember/feature-flags.md

@@ -9,22 +9,22 @@ Ember.js community considers them ready for production use.
 A newly-flagged feature is only available in canary builds and can be enabled
 at runtime through your project's configuration file.
 
-At the start of a beta cycle the Ember core team evaluates each new feature.
+At the start of a beta cycle, the Ember core team evaluates each new feature.
 Features deemed stable are made available in the next beta and enabled by default.
 
 Beta features that receive negative feedback from the community are disabled in the next beta point
-release, and are not included in the next stable release. They may still be included
+release and are not included in the next stable release. They may still be included
 in the next beta cycle if the issues/concerns are resolved.
 
-Once the beta cycle has completed, the next stable release will include any features that
-were enabled during the beta cycle. At this point the feature flags will be removed from
+Once the beta cycle has been completed, the next stable release will include any features that
+were enabled during the beta cycle. At this point, the feature flags will be removed from
 the canary and future beta branches, and the feature becomes part of the framework.
 
 ## Flagging Details
-The flag status in the generated build is controlled by the [`@ember/canary-features`](https://github.com/emberjs/ember.js/blob/master/packages/@ember/canary-features/index.ts)
+The flag status in the generated build is controlled by the [`@ember/canary-features`](https://github.com/emberjs/ember.js/blob/main/packages/@ember/canary-features/index.ts)
 package. This package exports a list of all available features and their current status.
 
-A feature can have one of a three flags:
+A feature can have one of three flags:
 
 * `true` - The feature is **present** and **enabled**: the code behind the flag is always enabled in
   the generated build.
@@ -36,12 +36,12 @@ A feature can have one of a three flags:
 The process of removing the feature flags from the resulting build output is
 handled by [`defeatureify`](https://github.com/thomasboyt/defeatureify).
 
-## Feature Listing ([`FEATURES.md`](https://github.com/emberjs/ember.js/blob/master/FEATURES.md))
+## Feature Listing ([`FEATURES.md`](https://github.com/emberjs/ember.js/blob/main/FEATURES.md))
 
-When a developer adds a new feature to the `canary` channel (i.e. the `master` branch on GitHub), they
-also add an entry to [`FEATURES.md`](https://github.com/emberjs/ember.js/blob/master/FEATURES.md)
+When a developer adds a new feature to the `canary` channel (i.e. the `main` branch on GitHub), they
+also add an entry to [`FEATURES.md`](https://github.com/emberjs/ember.js/blob/main/FEATURES.md)
 explaining what the feature does, and linking to their originating pull request.
-This list is kept current, and reflects what is available in each channel
+This list is kept current and reflects what is available in each channel
 (`release`, `beta`, and `canary`).
 
 ## Enabling At Runtime
@@ -52,7 +52,7 @@ feature by setting its flag value to `true` before your application boots:
 let ENV = {
   EmberENV: {
     FEATURES: {
-      'link-to': true
+      'LINK_TO': true
     }
   }
 };

guides/configuring-ember/handling-deprecations.md

@@ -29,9 +29,6 @@ export function initialize() {
 export default { initialize };
 ```
 
-The deprecation handler API was released in Ember 2.1.
-If you would like to leverage this API in a prior release of Ember you can install the [ember-debug-handlers-polyfill](http://emberobserver.com/addons/ember-debug-handlers-polyfill) addon into your project.
-
 ## Deprecation Workflow
 
 Once you've removed deprecations that you may not need to immediately address, you may still be left with many deprecations.

guides/ember-inspector/deprecations.md

@@ -15,8 +15,6 @@ list of sources for each deprecation. If you are using Chrome or Firefox,
 clicking on the source opens the sources panel and takes you to
 the code that caused the deprecation message to be displayed.
 
-<img src="/images/guides/ember-inspector/v4.3.4/deprecations-source.png" />
-
 <img src="/images/guides/ember-inspector/v4.3.4/deprecations-sources-panel.png" width="680"/>
 
 You can send the deprecation message's stack trace to the

guides/routing/specifying-a-routes-model.md

@@ -70,12 +70,9 @@ Let's compare some examples using the model hook to make asynchronous HTTP reque
 ### Fetch example
 
 First, here's an example using a core browser API called [`fetch`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API), which returns a Promise.
-Install [`ember-fetch`](https://github.com/ember-cli/ember-fetch) with the command `ember install ember-fetch`, if it is not already in the app's `package.json`.
-Older browsers may not have `fetch`, but the `ember-fetch` library includes a polyfill, so we don't have to worry about backwards compatibility!
 
 ```javascript {data-filename=app/routes/photos.js}
 import Route from '@ember/routing/route';
-import fetch from 'fetch';
 
 export default class PhotosRoute extends Route {
   async model() {

scripts/catchup.mjs

@@ -16,15 +16,15 @@ const argv = minimist(process.argv.slice(2), { string: ['from', 'to'] });
 // Read current Ember version (under translation)
 const currentEmberVersion = `${argv.from}`;
 if (currentEmberVersion.match(/\d+[.]\d+/g)?.[0] !== currentEmberVersion) {
-  raise(`please provide the current Ember version under translation to option ${chalk.cyan.bold('--from')} (e.g. --from=5.1)`)
+  raise(`please provide the current minor Ember version under translation to option ${chalk.cyan.bold('--from')} (e.g. --from=5.1)`)
   process.exit(9);
 }
 log(`Ember version under translation: ${chalk.cyan.bold(currentEmberVersion)}`);
 
 // Read new Ember version (documented by the English guides)
 const newEmberVersion = `${argv.to}`;
 if (newEmberVersion.match(/\d+[.]\d+/g)?.[0] !== newEmberVersion) {
-  raise(`please provide the new Ember version documented on upstream to option ${chalk.cyan.bold('--to')} (e.g. --to=5.4)`)
+  raise(`please provide the new minor Ember version documented on upstream to option ${chalk.cyan.bold('--to')} (e.g. --to=5.4)`)
   process.exit(9);
 }
 log(`New Ember version documented on upstream: ${chalk.cyan.bold(newEmberVersion)}`);

scripts/catchup/gitActions.mjs

@@ -19,7 +19,9 @@ export function initCatchup(catchupBranch) {
 export function pushGuides(currentEmberVersion, newEmberVersion, catchupBranch) {
   try {
     runShell('git add guides');
-    runShell(`git commit -m "feat: automatic catch up from ${currentEmberVersion} to ${newEmberVersion}"`);
+    // The commit hook blocks the commit if a changed file is not in .remarkignore, because it assumes change=translation,
+    // but here we have English-only modifications, so we use --no-verify to prevent the hook to execute.
+    runShell(`git commit -m "feat: automatic catch up from ${currentEmberVersion} to ${newEmberVersion}" --no-verify`);
     runShell(`git push origin ${catchupBranch}`);
   } catch (error) {
     throw new Error('Failed to push the catchup branch.');