All changes that effect library output should be documented in the Changelog as part of the pull request process, so when the main branch has changes that aren't released yet they will be documented under the 'main' title in the Changelog.
We use semver for our release naming but we’re currently pre-v1 so every change is a patch release, and may contain breaking changes.
It's preferable to group changes so we don't release a new version for every small change, but for fixes or urgent features it's okay to make releases for a small amount of changes.
Before publishing you need to authenticate with npm and RubyGems.
For RubyGems create an account with your personal email and set up two factor authentication. Ask an owner of the primer_view_components gem to add you as a contributor, and then run gem signin to authenticate with the CLI.
For npm create an account with your personal email and set up two factor authentication. Ask one of the collaborators on the @primer/view-components package to add you to the Primer team, then run npm adduser to authenticate with the CLI. You can confirm your authentication with npm whoami.
Releases are managed by 🦋 Changesets which is a great tool for managing major/minor/patch bumps and changelogs. More info can be found in our how we work docs.
We have the changeset-bot comment on new pull requests asking contributors or maintainers to add a changeset file, which will become the markdown supported changelog entry for the change.
When creating the changeset always commit into the working branch (pull request branch), not main.
When a pull request is approved merge it into the main branch. The changeset action will then create a Release pull request that includes this new pull request.
Once maintainers have agreed and are satisfied with the release. Merge the Release pull request. Changesets will then publish a new GitHub release to the repository with the changelog and new version number.
When the release pull request is merged into main, pull the changes and run script/publish to publish the library on rubygems and npm.
🎉 Congratulations! The new release has been published.
If you’ve released a version of the library that introduces significant visual regressions or unintended breaking changes the best thing to do is make a new release which reverts the offending changes. Do not include any other unreleased changes besides the reverts, as they could have unintended side-effects.
[Process TBC]
The documentation site and Storybook are automatically deployed by GitHub Action workflows when changes are made to the main branch. The documentation site is deployed with GitHub Pages (aliased from https://primer.github.io/view_components/) and Storybook is deployed with Azure as it relies on a live Rails server (aliased from view-components-storybook.eastus.cloudapp.azure.com).