Skip to content

Latest commit

 

History

History
39 lines (23 loc) · 2.05 KB

release.md

File metadata and controls

39 lines (23 loc) · 2.05 KB
Raw

Release

Release Notes

This project uses an different approach to release, driving it from changelog and versioned changelog notes instead of tagging.

Use changie quick start for basic review.

Creating New Notes

  • During development, new changes of note get tracked via changie new. This can span many pull requests, whatever makes sense as version to ship as changes to users.
  • To release the changes into a version, changie batch <major|minor|patch> (unless breaking changes occur, you'll want to stick with minor for feature additions, and patch for fixes or non app work.

Keep your summary of changes that users would care about in the .changes/ files it will create.

Release

Update CHANGELOG.md by running changie merge which will rebuild the changelog file with all the documented notes.

Format & Lint

  • Run trunk fmt --all; trunk check --all to finalize run through.
  • Push changelog via PR or direct if you have permissions and this will trigger the release-composite. If any issues, retrigger manually via gh workflow run release-composite.
  • Release should be published in the releases
  • Edit the release and click "update release" to ensure it publishes to the marketplace. Unfortunately, creating a release doesn't trigger the marketplace release without doing this step. While this can be automated through other actions, I've opted due to time constraints to leave that last step as a manual one.

FAQ

What drives the version number for the release?

Changie notes are named like v1.0.4.md. This version number will be used to set the version of the release, so the docs in essence will be the version source of truth.

Conventional Commit

We use conventional commit. Pull requests must adhere to this to be merged.

Description should be bullet point list or longer-form content to describe anything the title doesn't make clear.