Release 0.3.0

[markmandel]

Release 0.3.0

Prerequisites

• Have at least Editor level access to quilkin Google Cloud project.
• Local gcloud configuration is pointing at the quilkin Google Cloud project.
• Local git remote upstream points at [email protected]:googleforgames/quilkin.git.

Steps

• Review that closed issues have appropriate tags for the changelog.
• Review that merged PRs have appropriate tags for the changelog.
• Run git remote update && git checkout main && git reset --hard upstream/main to ensure your code is in line
  with upstream.
• Update Cargo version for release
  • Edit the version field in ./Cargo.toml and remove the -dev suffix.
  • Edit the quilkin-macros dependency in ./Cargo.toml and remove the -dev suffix.
  • Edit the version field in ./macros/Cargo.toml and remove the -dev suffix.
• cd to ./build/release and run make to submit the cloud build
• Download all the artifacts from the cloud build.
• Move the CHANGELOG.md to the root of this repository, replacing any previous versions.
• Review license.html to ensure that there aren't any new MPL, or CDDL dependencies from the last
  release. If there are:
  • Add the dependencies to archive_dependencies.sh
    so that the source is archived in the container image.
  • Reset checklist back to "run make to submit the cloud build", and start from there again.
• Run cd macros && cargo publish --dry-run --allow-dirty and ensure there are no issues.
• Run cargo publish --dry-run --allow-dirty and ensure there are no issues.
• Add a release item to README.md "Documentation" > "Releases" list with related links in reverse chronological
  order.
• Submit these changes as a PR, and merge with approval.
• Create a Github release using the
  Github release template.
  • Populate the tag with v0.3.0, description, and relevant changelog sections.
  • Attach all the remaining cloud build artifacts to the release.
• Run git remote update && git checkout main && git reset --hard upstream/main to ensure your code is in line
  with upstream.
• Run git checkout -b release-0.3.0 && git push upstream release-0.3.0 to create a release branch.
• Publish to crates.io/crates/quilkin-macros: run cd macros && cargo publish
• Publish to crates.io/crates/quilkin: run cargo publish
• Submit the release.
• Post an announcement to the mailing list.
• Post to the Twitter account.
• Update Cargo version for development
  • Edit Cargo.toml and increment the minor version and apply the -dev suffix to the
    version.
  • Edit the quilkin-macros dependency in ./Cargo.toml and increment the minor version
    and apply the -dev suffix to the version.
  • Edit the version field in ./macros/Cargo.tomland increment the minor version
    and apply the -dev suffix to the version.
• Submit this change as a PR, and merge with approval.

Congratulation! 🎉 You have successfully released Quilkin!

[markmandel]

Getting this setup. Will merge:

• Update to Rust 1.59 #496
• Update dependencies #497

Before continuing.

[XAMPPRocky]

Side-note: I think we could automate some of these steps to reduce the friction of making Quilkin releases. They'd also be good first issues, @markmandel would you be interested in making a couple of issues for some of the things in the list you think could be automated?

[markmandel]

@XAMPPRocky anything in particular that jumps out at you? 🤔 I think you had some tools for incrementing crate versions I think?

[markmandel]

Twitter account post is scheduled for tomorrow PST morning (9:07am) - I find I get best engagement around that time.

[XAMPPRocky]

Closing as complete.

anything in particular that jumps out at you?

I think all of the steps could be automated to be honest. In particular all of the commands about ensuring that the state of the repository is both the state it should be in, and working as expected could definitely be reduced to a single command.

In my mind I think as a goal, we should have a nearly entirely automated release pipeline so that we can release a new version of Quilkin with one push of a button (within reason of course). Like it would be great if we just had a manual GitHub Action so that you could just input the next dev version, and have CI take care of the rest.

https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/