Skip to content

checklist-make-a-new-quarto-release.md

Latest commit

 

History

History
85 lines (83 loc) · 6.81 KB

checklist-make-a-new-quarto-release.md

File metadata and controls

85 lines (83 loc) · 6.81 KB

  • 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

  • mark v1.4 release as stable

  • 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
    • 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)
    • pypi
      • Go to the quarto-cli-pypi repo
      • 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 
              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
        • Take a sip of tea ☕, bask in the glory of automation.
    • Others installers
      • Cloudsmith: Automatically published by Build Installers workflow. No action 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