diff --git a/.github/workflows/cla.yml b/.github/workflows/cla.yml index ddc0516..04b3e1c 100644 --- a/.github/workflows/cla.yml +++ b/.github/workflows/cla.yml @@ -18,7 +18,7 @@ jobs: runs-on: ubuntu-latest steps: - name: Check CLA - uses: conda/actions/check-cla@15f883f14f4232f83658e3609c3316d58905138f # v24.8.0 + uses: conda/actions/check-cla@6e72e0db87e72f0020e493aeb02f864363bd9258 # v24.11.1 with: # [required] # A token with ability to comment, label, and modify the commit status diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml index 9d23fbe..cf82ffe 100644 --- a/.github/workflows/stale.yml +++ b/.github/workflows/stale.yml @@ -33,7 +33,7 @@ jobs: days-before-issue-stale: 90 days-before-issue-close: 21 steps: - - uses: conda/actions/read-yaml@15f883f14f4232f83658e3609c3316d58905138f # v24.8.0 + - uses: conda/actions/read-yaml@6e72e0db87e72f0020e493aeb02f864363bd9258 # v24.11.1 id: read_yaml with: path: https://raw.githubusercontent.com/conda/infra/main/.github/messages.yml diff --git a/.github/workflows/update.yml b/.github/workflows/update.yml index df69f36..90ee32b 100644 --- a/.github/workflows/update.yml +++ b/.github/workflows/update.yml @@ -55,11 +55,11 @@ jobs: git config --global user.name 'Conda Bot' git config --global user.email '18747875+conda-bot@users.noreply.github.com' - - uses: conda/actions/combine-durations@15f883f14f4232f83658e3609c3316d58905138f # v24.8.0 + - uses: conda/actions/combine-durations@6e72e0db87e72f0020e493aeb02f864363bd9258 # v24.11.1 id: durations continue-on-error: true - - uses: conda/actions/template-files@15f883f14f4232f83658e3609c3316d58905138f # v24.8.0 + - uses: conda/actions/template-files@6e72e0db87e72f0020e493aeb02f864363bd9258 # v24.11.1 id: templates continue-on-error: true diff --git a/RELEASE.md b/RELEASE.md index b826567..1f415ff 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -13,12 +13,12 @@ # Release Process > [!NOTE] -> Throughout this document are references to the version number as `MAJOR.MINOR.[$patch_number]`, this should be replaced with the correct version number. Do **not** prefix the version with a lowercase `v`. +> Throughout this document are references to the version number as `MAJOR.MINOR`, this should be replaced with the correct version number. Do **not** prefix the version with a lowercase `v`. ## 1. Open the release issue and cut a release branch. (do this ~1 week prior to release) > [!NOTE] -> The new release branch should adhere to the naming convention of `MAJOR.MINOR.x` (make sure to put the `.x` at the end!). In the case of patch/hotfix releases, however, do NOT cut a new release branch; instead, use the previously-cut release branch with the appropriate `MAJOR.MINOR.x` version numbers. +> The new release branch should adhere to the naming convention of `` (note the difference to `MAJOR.MINOR`). In the case of patch/hotfix releases, however, do NOT cut a new release branch; instead, use the previously-cut `` release branch. Use the issue template below to create the release issue. After creating the release issue, pin it for easy access. @@ -28,7 +28,7 @@ Use the issue template below to create the release issue. After creating the rel ```markdown ### Summary -Placeholder for `conda-content-trust MAJOR.MINOR.x` release. +Placeholder for `conda-content-trust ` release. | Pilot | | |---|---| @@ -46,8 +46,8 @@ Placeholder for `conda-content-trust MAJOR.MINOR.x` release.

The week before release week

 -- [ ] Create release branch (named `MAJOR.MINOR.x`) -- [ ] Ensure release candidates are being successfully built (see `conda-canary/label/rc-conda-content-trust-MAJOR.MINOR.x`) +- [ ] Create release branch (named ``) +- [ ] Ensure release candidates are being successfully built (see `conda-canary/label/rc-conda-content-trust-`) - [ ] [Complete outstanding PRs][milestone] - [ ] Test release candidates @@ -59,8 +59,8 @@ Placeholder for `conda-content-trust MAJOR.MINOR.x` release. - [ ] Create release PR (see [release process][process]) - [ ] [Publish release][releases] -- [ ] Merge `MAJOR.MINOR.x` back into `main` -- [ ] Activate the `MAJOR.MINOR.x` branch on [ReadTheDocs][ReadTheDocs] +- [ ] Merge `` back into `main` +- [ ] Activate the `` branch on [ReadTheDocs][ReadTheDocs] - [ ] Feedstocks - [ ] Bump version & update dependencies/tests in [Anaconda, Inc.'s feedstock][main] - [ ] Bump version & update dependencies/tests in [conda-forge feedstock][conda-forge] @@ -87,12 +87,12 @@ If a patch release is necessary, reopen the original release issue and append th ```markdown
-

Patch MAJOR.MINOR.[$patch_number]

 +

Patch MAJOR.MINOR

 - [ ] - [ ] Create release PR (see [release process][process]) - [ ] [Publish release][releases] -- [ ] Merge `MAJOR.MINOR.x` back into `main` +- [ ] Merge `` back into `main` - [ ] Feedstocks - [ ] Bump version & update dependencies/tests in [Anaconda, Inc.'s feedstock][main] - [ ] Bump version & update dependencies/tests in [conda-forge feedstock][conda-forge] @@ -106,6 +106,9 @@ If a patch release is necessary, reopen the original release issue and append th > [!NOTE] > The [epic template][epic template] is perfect for this; remember to remove the **`epic`** label. +> [!NOTE] +> A patch release is like a regular, i.e., follow the same steps in the process as you would for a regular release. Most patches are authored by existing contributors (most likely maintainers themselves) so running `rever ` may succeed on the first pass. + ## 2. Alert various parties of the upcoming release. (do this ~1 week prior to release) Let various interested parties know about the upcoming release; at minimum, conda-forge maintainers should be informed. For major features, a blog post describing the new features should be prepared and posted once the release is completed (see the announcements section of the release issue). @@ -114,7 +117,7 @@ Let various interested parties know about the upcoming release; at minimum, cond ### Canary Builds for Manual Testing -Once the release PRs are filed, successful canary builds will be available on `https://anaconda.org/conda-canary/conda/files?channel=rc-conda-content-trust-MAJOR.MINOR.x` for manual testing. +Once the release PRs are filed, successful canary builds will be available on `/conda-content-trust/files?channel=rc-conda-content-trust-` for manual testing. > [!NOTE] > You do not need to apply the `build::review` label for release PRs; every commit to the release branch builds and uploads canary builds to the respective `rc-` label. @@ -147,13 +150,13 @@ Currently, there are only 2 activities we use rever for, (1) aggregating the aut ```bash (rever) $ git fetch upstream - (rever) $ git checkout MAJOR.MINOR.x + (rever) $ git checkout ``` 2. Create a versioned branch, this is where rever will make its changes: ```bash - (rever) $ git checkout -b changelog-MAJOR.MINOR.[$patch_number] + (rever) $ git checkout -b changelog-MAJOR.MINOR ``` 2. Run `rever --activities authors `: @@ -181,7 +184,7 @@ Currently, there are only 2 activities we use rever for, (1) aggregating the aut - Here's a sample run where we undo the commit made by rever in order to commit the changes to `.authors.yml` separately: ```bash - (rever) $ rever --activities authors --force MAJOR.MINOR.[$patch_number] + (rever) $ rever --activities authors --force MAJOR.MINOR # changes were made to .authors.yml as per the prior bullet (rever) $ git diff --name-only HEAD HEAD~1 @@ -250,7 +253,7 @@ Currently, there are only 2 activities we use rever for, (1) aggregating the aut > * Add `win-arm64` as a known platform (subdir). (#11778) > ``` - - You can utilize [GitHub's compare view][compare] to review what changes are to be included in this release. Make sure you compare the current release branch against the previous one (e.g., `24.5.x` would be compared against `24.3.x`) + - You can utilize [GitHub's compare view][compare] to review what changes are to be included in this release. Make sure you compare the current release branch against the previous one - Add a new news snippet for any PRs of importance that are missing. @@ -310,8 +313,8 @@ Currently, there are only 2 activities we use rever for, (1) aggregating the aut + 86957814cf235879498ed7806029b8ff5f400034 Update .authors.yml + 3ec7491f2f58494a62f1491987d66f499f8113ad Update .mailmap + 432a9e1b41a3dec8f95a7556632f9a93fdf029fd Update news - + a5c0db938893d2c12cab12a1f7eb3e646ed80373 Update authorship for MAJOR.MINOR.[$patch_number] - + 5e95169d0df4bcdc2da9a6ba4a2561d90e49f75d Update CHANGELOG for MAJOR.MINOR.[$patch_number] + + a5c0db938893d2c12cab12a1f7eb3e646ed80373 Update authorship for MAJOR.MINOR + + 5e95169d0df4bcdc2da9a6ba4a2561d90e49f75d Update CHANGELOG for MAJOR.MINOR ``` 7. Since rever does not include stats on first-time contributors, we will need to add this manually. @@ -332,18 +335,18 @@ Currently, there are only 2 activities we use rever for, (1) aggregating the aut + 86957814cf235879498ed7806029b8ff5f400034 Update .authors.yml + 3ec7491f2f58494a62f1491987d66f499f8113ad Update .mailmap + 432a9e1b41a3dec8f95a7556632f9a93fdf029fd Update news - + a5c0db938893d2c12cab12a1f7eb3e646ed80373 Update authorship for MAJOR.MINOR.[$patch_number] - + 5e95169d0df4bcdc2da9a6ba4a2561d90e49f75d Update CHANGELOG for MAJOR.MINOR.[$patch_number] + + a5c0db938893d2c12cab12a1f7eb3e646ed80373 Update authorship for MAJOR.MINOR + + 5e95169d0df4bcdc2da9a6ba4a2561d90e49f75d Update CHANGELOG for MAJOR.MINOR + 93fdf029fd4cf235872c12cab12a1f7e8f95a755 Add first-time contributions ``` 8. Push this versioned branch. ```bash - (rever) $ git push -u upstream changelog-MAJOR.MINOR.[$patch_number] + (rever) $ git push -u upstream changelog-MAJOR.MINOR ``` -9. Open the Release PR targing the `MAJOR.MINOR.x` branch. +9. Open the Release PR targeting the `` branch.
GitHub PR Template @@ -367,8 +370,8 @@ Currently, there are only 2 activities we use rever for, (1) aggregating the aut | Field | Value | |---|---| - | Choose a tag | `MAJOR.MINOR.[$patch_number]` | - | Target | `MAJOR.MINOR.x` | + | Choose a tag | `MAJOR.MINOR` | + | Target | `` | | Body | copy/paste blurb from `CHANGELOG.md` |
@@ -389,14 +392,14 @@ To publish the release, go to the project's release page (e.g., https://github.c 1. From the main "< > Code" page of the repository, select the drop down menu next to the `main` branch button and then select "View all branches" at the very bottom. -2. Find the applicable `MAJOR.MINOR.x` branch and click the "New pull request" button. +2. Find the applicable `` branch and click the "New pull request" button. -3. "Base" should point to `main` while "Compare" should point to `MAJOR.MINOR.x`. +3. "Base" should point to `main` while "Compare" should point to ``. 4. Ensure that all of the commits being pulled in look accurate, then select "Create pull request". > [!NOTE] -> Make sure NOT to push the "Update Branch" button. If there are [merge conflicts][merge conflicts], create a temporary "connector branch" dedicated to fixing merge conflicts separately from the `MAJOR.MINOR.x` and `main` branches. +> Make sure NOT to push the "Update Branch" button. If there are [merge conflicts][merge conflicts], create a temporary "connector branch" dedicated to fixing merge conflicts separately from the `` and `main` branches. 5. Review and merge the pull request the same as any code change pull request. @@ -405,7 +408,7 @@ To publish the release, go to the project's release page (e.g., https://github.c
-## 9. Open PRs to bump [Anaconda Recipes][Anaconda Recipes] and [conda-forge][conda-forge] feedstocks to use `MAJOR.MINOR.[$patch_number]`. +## 9. Open PRs to bump [Anaconda Recipes][Anaconda Recipes] and [conda-forge][conda-forge] feedstocks to use `MAJOR.MINOR`. > [!NOTE] > Conda-forge's PRs will be auto-created via the `regro-cf-autotick-bot`. Follow the instructions below if any changes need to be made to the recipe that were not automatically added (these instructions are only necessary for anyone who is _not_ a conda-forge feedstock maintainer, since maintainers can push changes directly to the autotick branch):