-
Notifications
You must be signed in to change notification settings - Fork 996
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(docs): background check documentation update #11599
base: main
Are you sure you want to change the base?
Conversation
If you'd like to get notified (at most, once a day) when there's a new version, set `versionUpdates` to an array of the version tags you're interested in (tags listed earlier take priority). | ||
While you can specify any tag, common options include: `latest`, `canary`, `next`, or `rc`. | ||
|
||
To opt out of background version checks entirely, simply remove the `versionUpdates` option, comment it out, or set its value to an empty array `[""]`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is me guessing here on ways to disable this. I have not tested these! 🙏
Also - I am waiting for approval/any modifications and then I will update and port back to v6(?). |
Right now it can only check for new versions. | ||
If you'd like it to do so, set `notifications.versionUpdates` in the `redwood.toml` file to include an array of the tags you're interested in hearing about. | ||
(The former has priority.) | ||
Right now it defaults to check for a new `latest` version. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now it defaults to check for a new `latest` version. | |
Right now it defaults to check for a new "latest" version. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think "checking" is the more correct form of the verb here 🙂
If you'd like it to do so, set `notifications.versionUpdates` in the `redwood.toml` file to include an array of the tags you're interested in hearing about. | ||
(The former has priority.) | ||
Right now it defaults to check for a new `latest` version. | ||
To customize this behavior - perhaps by checking for `rc` (release candidate) or other tags - set `notifications.versionUpdates` in the `redwood.toml` file to include an array of the tags you're interested in. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To customize this behavior - perhaps by checking for `rc` (release candidate) or other tags - set `notifications.versionUpdates` in the `redwood.toml` file to include an array of the tags you're interested in. | |
To customize this behavior - perhaps by checking for "rc" (release candidate) or other tags - set `notifications.versionUpdates` in the `redwood.toml` file to include an array of the tags you're interested in. |
@@ -165,7 +165,10 @@ These options allows you to disable the generation of test and story files. | |||
There are new versions of the framework all the time—a major every couple months, a minor every week or two, and patches when appropriate. | |||
And if you're on an experimental release line, like canary, there's new versions every day, multiple times. | |||
|
|||
If you'd like to get notified (at most, once a day) when there's a new version, set `versionUpdates` to include the version tags you're interested in. | |||
If you'd like to get notified (at most, once a day) when there's a new version, set `versionUpdates` to an array of the version tags you're interested in (tags listed earlier take priority). | |||
While you can specify any tag, common options include: `latest`, `canary`, `next`, or `rc`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While you can specify any tag, common options include: `latest`, `canary`, `next`, or `rc`. | |
While you can specify any tag, common options include: "latest", "canary", "next", or "rc" "experimental", or a valid semver version. |
These notes exist in the upgrade.js file... if these are all still valid tags, then I will update this PR to the above suggestion.
.option('tag', {
alias: 't',
description:
'[choices: "latest", "rc", "next", "canary", "experimental", or a specific-version (see example below)] WARNING: "canary", "rc" and "experimental" are unstable releases! And "canary" releases include breaking changes often requiring codemods if upgrading a project.',
requiresArg: true,
type: 'string',
coerce: validateTag,
})
and
if (!isTagValid) {
// Stop execution
throw new Error(
c.error(
"Invalid tag supplied. Supported values: 'rc', 'canary', 'latest', 'next', 'experimental', or a valid semver version\n",
),
)
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you're going with your suggestion Barrett there are a couple of small tweaks I'd do to it. Right now there are two "or", and a missing comma.
With those corrections it'd look like this:
While you can specify any tag, common options include: "latest", "canary", "next", "rc", "experimental", or a valid semver version.
I'll let @Josh-Walker-GM comment on the validity of all those choices
Updated the documentation around automated background checks to reflect that it is
latest
,canary
,next
, orrc
This information spans two documents. Since the two documents interact, I added a link from the background check section to the TOML configuration section.