diff --git a/docs/storefront/catalyst/getting-started/versioning.mdx b/docs/storefront/catalyst/getting-started/versioning.mdx index ff1240148..513ee654e 100644 --- a/docs/storefront/catalyst/getting-started/versioning.mdx +++ b/docs/storefront/catalyst/getting-started/versioning.mdx @@ -15,14 +15,13 @@ For the most recent stable code, refer to [How we use tags](#how-we-use-tags) be We create Github Releases from Git tags to indicate distributable releases of Catalyst. To get the latest stable release of Catalyst, you can use the following tags: - Catalyst - `@bigcommerce/catalyst-core@latest` -- Catalyst (with Makeswift) - `@bigcommerce/catalyst-core@makeswift-latest` +- Catalyst (with Makeswift) - `@bigcommerce/catalyst-makeswift@latest` - - Until version 1.0 of Catalyst is released, the release deployed using - [One-Click Catalyst](/docs/storefront/catalyst/getting-started/workflows/one-click-catalyst) will be from the - `@bigcommerce/catalyst-core@makeswift-canary` tag and **is not guranteed to be - stable**. After 1.0 is released, this will move to use the - `@bigcommerce/catalyst-core@makeswift-latest` which will be stable. + + As of Catalyst v1.0.0 release, the release deployed using + [One-Click Catalyst](/docs/storefront/catalyst/getting-started/workflows/one-click-catalyst) uses the + stable `@bigcommerce/catalyst-makeswift@latest` tag. For development and + testing purposes, canary releases are available via the `@bigcommerce/catalyst-makeswift@canary` tag. You can also find a list of all [Catalyst release tags](https://github.com/bigcommerce/catalyst/tags) in the Catalyst repository. diff --git a/docs/storefront/catalyst/getting-started/workflows/integrate.mdx b/docs/storefront/catalyst/getting-started/workflows/integrate.mdx index 778e59594..75c13a25e 100644 --- a/docs/storefront/catalyst/getting-started/workflows/integrate.mdx +++ b/docs/storefront/catalyst/getting-started/workflows/integrate.mdx @@ -29,8 +29,8 @@ Now, you can begin to write the code required to make your integration work! There are a handful of lessons we have learned from building integrations into Catalyst ourselves; we wanted to offer those lessons as tips to follow while building your own integration. You should highly consider incorporating these tips into your own workflow, as we have found it has saved us time and headache. -1. Keep your integration code as maintainable as possible. You'll notice that the [`integrations/makeswift` branch](https://github.com/bigcommerce/catalyst/compare/main...integrations/makeswift) has only a single commit, and about 20 changed files. This means that merge conflicts caused rebasing on top of the latest `upstream/main` to update your integration are easier to deal with. -2. Explicitly call out when your integration makes use of newly introduced environment variables. You'll notice that the [`integrations/makeswift` branch](https://github.com/bigcommerce/catalyst/compare/main...integrations/makeswift) adds a new environment variable called `MAKESWIFT_SITE_API_KEY`; by explicitly listing newly introduced environment variables in a version-controlled file like `.env.example`, it makes it obvious to the consumers of your integration when they need to add new environment variables to make your integration work. +1. Keep your integration code as maintainable as possible. You'll notice that the [`integrations/makeswift` branch](https://github.com/bigcommerce/catalyst/compare/canary...integrations/makeswift) has only a single commit, and about 20 changed files. This means that merge conflicts caused rebasing on top of the latest `upstream/canary` to update your integration are easier to deal with. +2. Explicitly call out when your integration makes use of newly introduced environment variables. You'll notice that the [`integrations/makeswift` branch](https://github.com/bigcommerce/catalyst/compare/canary...integrations/makeswift) adds a new environment variable called `MAKESWIFT_SITE_API_KEY`; by explicitly listing newly introduced environment variables in a version-controlled file like `.env.example`, it makes it obvious to the consumers of your integration when they need to add new environment variables to make your integration work. ### Open a PR to add your integration to upstream @@ -38,11 +38,11 @@ Now that your branch is ready for public use, please start by opening a new issu ### Keeping your integration up to date -Keeping your integration up to date is as simple as rebasing your integration branch on top of the latest changes introduced to `upstream/main`, and then opening a PR from your origin remote fork integration branch into the integration branch with the same name on the upstream remote repository. +Keeping your integration up to date is as simple as rebasing your integration branch on top of the latest changes introduced to `upstream/canary`, and then opening a PR from your origin remote fork integration branch into the integration branch with the same name on the upstream remote repository. ```shell copy git checkout integrations/ -git fetch upstream main -git pull --rebase upstream main +git fetch upstream canary +git pull --rebase upstream canary git push --force-with-lease origin integrations/ ```