- [ ] ensure your git repo is up to date with `main`
- [ ] create a branch `v1.x`, where x is the version being released
  - `git checkout -b v1.4`
  - `git push origin v1.4`
- [ ] mark the current release as the new release in the `main` branch
  - [ ] switch your repo back to `main`: `git checkout main`
  - [ ] edit QUARTO_VERSION line in `/configuration` to be the new version (e.g. `1.5`)
  - [ ] push the changes to the `main` branch
  - [ ] kick off a v1.5 build in GHA: https://github.com/quarto-dev/quarto-cli/actions/workflows/create-release.yml
    - [ ] ensure the build completes successfully
- [ ] mark v1.4 release as stable
  - [ ] go to https://github.com/quarto-dev/quarto-cli/releases
  - [ ] find the latest v1.4 release and edit, (eg https://github.com/quarto-dev/quarto-cli/releases/edit/v1.4.549)
  - [ ] at the bottom of the page, there will be two checkboxes, "Set as pre-release" and "Set as latest release":
    - [ ] "Set as pre-release" should be unchecked, and
    - [ ] "Set as latest release" should be checked.
- [ ] once the v1.5 build completes, edit the quarto.org website configuration on https://github.com/quarto-dev/quarto-web to reflect the new version
  - this means flipping the profile group configuration in `_quarto.yml` from `[rc,prelease]` to `[prerelease,rc]`
    - [ ] push the changes to the `main` branch
- [ ] quarto-dev/quarto-web changes

  - wait for the downloads file to be automatically updated by the GitHub Action on https://github.com/quarto-dev/quarto-web
    - [ ] wait for https://github.com/quarto-dev/quarto-web/actions/workflows/update-downloads.yml to run (it runs every 15 minutes, or you can manually trigger it)
      - This workflow run rendered the website: https://github.com/quarto-dev/quarto-web/actions/runs/12016407762
      - This workflow run did not: https://github.com/quarto-dev/quarto-web/actions/runs/12016128695
      - [ ] Ensure the run just triggered looks like the _former_
      - [ ] Ensure the header in https://quarto.org has the new version number in its 'generator' meta tag
      - [ ] Ensure the download links on https://quarto.org/docs/get-started/ and https://quarto.org/docs/download/ point to the stable and prerelease versions respectively
  - In the `prerelease` branch:
    - [ ] update the highlights files
      - [ ] create `docs/prerelease/1.5/{_highlights, index}.qmd` files based on the ones from the previous release
      - [ ] change `docs/prerelease/_highlights.qmd` so its include points to the new version-specific `_highlights.qmd` file (here, 1.5)
      - [ ] change `docs/prerelease/_highlights-release.qmd` so its include points to the new version-specific `_highlights.qmd` file (here, 1.4)
    - [ ] add the stable version to the older downloads list by editing /docs/download/\_download-older.yml
    - [ ] run `quarto run tools/release-notes.R` to generate the release notes and bump `version` in `_quarto.yml` (to released version) and `_quarto-prerelease-docs.yml` (to next prerelease)
  - [ ] push the changes to `prerelease` branch, ensure they build correctly
  - [ ] Merge the `prerelease` branch into `main`, push to `main`
    - [ ] ensure the build completes successfully
    - [ ] verify `_quarto.yml` `version` on `main` reflects the released version (e.g. `'1.4'`) — needed for `prerelease` shortcodes to resolve blog links and pre-release callouts
  - [ ] Merge `main` into `prerelease`, push to `prerelease`
    - [ ] ensure the build completes successfully
  - [ ] Create new tag on `main` with stable release version number (here, `v1.4`) to mark when the new main site version went live
    - [ ] `git tag -a v1.4 -m "v1.4"`
    - [ ] `git push origin v1.4`
  - [ ] Verify version numbers were updated by `tools/release-notes.R`
    - [ ] `_quarto.yml` `version` should be the released version (e.g. `'1.4'`)
    - [ ] `_quarto-prerelease-docs.yml` `version` should be the next prerelease (e.g. `'1.5'`)
  - [ ] publish the release blog post that should exist in https://github.com/quarto-dev/quarto-web/tree/main/docs/blog/posts
    - [ ] Create a branch off of `main` (to trigger our PR automation to make the corresponding change to `prerelease`).
    - [ ] Removing the `draft: true` line in the metadata
    - [ ] Change the date to match the release date.

- [ ] Update https://github.com/quarto-dev/quarto-cli/blob/main/CITATION.cff
- [ ] Packaging and package managers, etc
  - [ ] chocolatey (Only once quarto.org download page is updated with the new release)
    - https://github.com/quarto-dev/quarto-release-bundles/actions/workflows/build-and-publish-choco.yaml
    - [ ] In "Build Choco package & Publish" workflow page, click "Run Workflow"
      - Check the "Whether to publish or not the package on chocolatey" checkbox
    - Wait for @cderv to receive email confirmation, no action needed
  - [ ] pypi
    - Go to the [quarto-cli-pypi repo](https://github.com/quarto-dev/quarto-cli-pypi)
    - [ ] Update `version.txt` to be the version you'd like to publish and commit
    - Go to actions
      - Select 'Publish Quarto PyPi'
      - [ ] Click "Run Workflow"
        - **Publishing Test**: You may elect to publish to test.pypi first by _unchecking_ the `Production Release` option
          - Once complete, trest using
            ```bash
            python3 -m pip install --index-url https://test.pypi.org/ --extra-index-url https://pypi.org/ quarto-cli
            ```
          - You may have to run this command twice as the first time may report the package not found and cause cache invalidation. The next try should succeed.
          - Published to: <https://test.pypi.org/project/quarto-cli/>
        - **Publishing Production**: You may elect to publish to production pypyi by checking the `Production Release` option
          - Published to: <https://pypi.org/project/quarto-cli/>
      - Take a sip of tea ☕, bask in the glory of automation.
  - Others installers
    - Cloudsmith: Automatically published by Build Installers workflow. No action needed.
      - See [cloudsmith-publishing.md](cloudsmith-publishing.md) for manual republishing if needed.
    - conda-forge: An automated PR will be created to update the package version in the feedstock <github.com/conda-forge/quarto-feedstock>
      - This is community maintained, so no action is needed from us - except maybe helping if there are issues with the PR. We are assigned as reviewers to the PR.
    - Winget: An automated PR will be created by a winget bot in <github.com/microsoft/winget-pkgs/>.
      - This is community maintained, so no action is needed from us.
    - Scoop: This will be updated automatically in the manifests repo. No action is needed from us. Maintained as personal project by @cderv.
    - Homebrew: This is automated through an homebrew bot to update the cask <https://github.com/Homebrew/homebrew-cask>
      - Manifest: <https://github.com/Homebrew/homebrew-cask/blob/master/Casks/q/quarto.rb>
