Updated release flow #118 #141
Conversation
| For example: `sr-accordion-component-112` | ||
|
|
||
| ### Conventional Commits | ||
|
|
There was a problem hiding this comment.
I think we should either describe or link here to examples of how commit messages should look for this standard.
The most important part (in my mind) is that people are aware of how to highlight a breaking changes specifically in their message. Particularly since we may use that to eventually automate the version bump down the road.
CHANGELOG.md
Outdated
| @@ -1,38 +1,29 @@ | |||
| # Changelog | |||
|
|
|||
| All notable changes to this project will be documented in this file. | |||
| All notable changes to this project will be documented in this file. See [standard-version](https://github.com/conventional-changelog/standard-version) for commit guidelines. | |||
There was a problem hiding this comment.
When is the changelog to be updated now? Is there still a manual change needed when merging new work? i.e. the developer should update changelog with unreleased changes before merging into develop? Or are we only updating the changelog now on version releases with standard-version?
There was a problem hiding this comment.
The latter - changelog will only be updated on version releases using standard-version
docs/contributing.md
Outdated
| This project uses a few tools to help standardize contributions and a streamlined release flow: | ||
|
|
||
| - [`commitlint`](https://github.com/conventional-changelog/commitlint) git hook, using the [conventional commits config](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) | ||
| - [`commitizen`](https://commitizen.github.io/cz-cli/) CLI for making it easy to write standard commit messages |
There was a problem hiding this comment.
should we also reference standard-version again here?
docs/contributing.md
Outdated
|
|
||
| 2. Create the release candidate branch (note that version numbers should _never_ be prefixed with `v`): | ||
| ### Releasing |
There was a problem hiding this comment.
I thought the point of this change (esp using semantic release) was to make every merge to develop trigger a release based on the merge commit message.
These new docs sound like we still want to follow a manual release process...?
docs/contributing.md
Outdated
| npm publish | ||
| ``` | ||
| ``` | ||
| npm publish |
There was a problem hiding this comment.
Why are we doing this from dev machines rather than from CI?
|
@sojeri The point is to have a more automated change, but I don't want to run before we can walk, and felt that using semantic release right off the bat on this project was overkill. This update will establish a standard for commit messages so we can start having an auto-generated changelog & version numbers, which will take most of the currently manual work out of the release flow. Determining how and when to do fully automated new stable releases is later down the line IMO. |
| - Prettier (auto-formatting) and eslint are run on _staged files_ as a pre-commit hook | ||
| - For an optimal developer experience, it's recommended that you configure your editor to run linting/formatting inline. | ||
| - All tests must pass, and eslint is run on all files in CircleCI | ||
| (TODO) Passing `develop` builds will automatically be published to the `next` tag on NPM. This allows users to easily test out the latest version in their applications, which may be unstable. |
There was a problem hiding this comment.
Calling this out as a TODO - need to add GH workflow for this
| ``` | ||
|
|
||
| Publishing access is limited to package owners. If you need access and don't have it, please contact `@npm-admins` on Slack. | ||
| 1. Once the release PR is approved, complete the release and publish the new version (this should be automated by GH - TODO): |
There was a problem hiding this comment.
Calling this out as a TODO - need to add GH workflow for this
| chalk "2.4.2" | ||
| get-stdin "7.0.0" | ||
| lodash "4.17.15" | ||
| meow "5.0.0" |
There was a problem hiding this comment.
This meow dependency is bringing in more of the bad yargs-parser versions. I'm seeing at least one commitlint/cli PR attempting to address this, so it may get patched soon.
standard-version suffers the same issue, though it's more indirect (through conventional-recommended-bump and mocha). This one doesn't have an open issue or PR yet, so may take longer to get patched if we don't engage.
There was a problem hiding this comment.
This meow dependency is bringing in more of the bad yargs-parser versions. I'm seeing at least one commitlint/cli PR attempting to address this, so it may get patched soon.
standard-versionsuffers the same issue, though it's more indirect (throughconventional-recommended-bumpandmocha). This one doesn't have an open issue or PR yet, so may take longer to get patched if we don't engage.
this was mentioned in our check-in today, but for posterity: we're going to add an ADR around our stance re: merging in dependencies that have open vulnerabilities, but tldr is that they should not block work, especially if low severity, and especially if in devDependencies (which won't end up in production code)
New & improved release workflow 🎉
I've made these changes with the desire to better streamline the release flow process, which is currently 100% manual. That said, this PR does not fully automate releases -- I want to make sure we're being very deliberate with every step, and not try to configure full end-to-end automation pre-maturely. I believe these changes will introduce minimal disruption into our current process, but make enough change to put us on track towards automated releases.
buildcommand toprepublishOnly(so the project doesn't get built on everyyarn install)There are 2 outstanding things I would like to continue working on, but felt the changes on this branch were far enough along that it can be reviewed and merged as-is. The big win in this PR is getting commit linting into the project ASAP so that our next set of release notes can be generated automatically. New issues for the remaining TODOs are:
Fixes #118