Conversation
316be6d to
3a10de7
Compare
| "$schema": "https://unpkg.com/@changesets/config@3.1.2/schema.json", | ||
| "access": "public", | ||
| "baseBranch": "master", | ||
| "bumpVersionsWithWorkspaceProtocolOnly": true, |
There was a problem hiding this comment.
This assumes we're using those odious workspace:^ version entries everywhere we should.
| "changelog": [ | ||
| "@changesets/changelog-github", | ||
| { | ||
| "repo": "endojs/endo" | ||
| } | ||
| ], |
There was a problem hiding this comment.
If we don't like this, it's pretty trivial to write our own changelog-generating plugin.
| "repo": "endojs/endo" | ||
| } | ||
| ], | ||
| "commit": false, |
There was a problem hiding this comment.
This means "don't automatically commit after adding a Changeset". If enabled, we can specify what the commit message should look like. I don't have an opinion about this.
3a10de7 to
845e07b
Compare
| "privatePackages": { | ||
| "tag": true, | ||
| "version": true | ||
| }, |
There was a problem hiding this comment.
we have a lot of private packages. I figure we want to version and tag them and add release notes like any other (why not?).
| "tag": true, | ||
| "version": true | ||
| }, | ||
| "updateInternalDependencies": "patch" |
| "baseBranch": "master", | ||
| "bumpVersionsWithWorkspaceProtocolOnly": true, | ||
| "changelog": [ | ||
| "@changesets/changelog-github", |
There was a problem hiding this comment.
this changelog-generator plugin adds references to GitHub PRs, commits, etc. the default generator does not.
845e07b to
a858b45
Compare
| permissions: | ||
| contents: write | ||
| pull-requests: write |
There was a problem hiding this comment.
I think this is sufficient.
kriskowal
left a comment
There was a problem hiding this comment.
Exciting. Let’s give this a hearing at the Endo meeting and move toward a first release with this process soon.
|
| on: | ||
| push: | ||
| branches: | ||
| - master |
There was a problem hiding this comment.
Does this mean we’re going to always have a release PR ready to go?
There was a problem hiding this comment.
Not always, but as long as there are changesets sitting in .changeset/.
| - name: Install Dependencies | ||
| run: yarn | ||
|
|
||
| - name: Create Release Pull Request |
|
We'll have to stick with |
Overview
This PR adopts Changesets for versioning and releasing.
Changesets are a solution to the problem of versioning and updating release notes. Unlike other solutions which generate release notes from Conventional Commits, Changesets do not prescribe a commit message format and provide more granular control over the contents of release notes. Instead, it keeps information about versions and release notes in a temporary file-based "database". These files are committed to version control, then "flushed" upon release.
Adding Changesets
To add a Changeset to your PR, you'll interface with
@changesets/cli, which will ask you to choose whether the Changeset represents a patch, minor, or major version bump. It will also ask you to provide a changelog entry. That entry replaces our current convention for updating aNEWS.mdfile.Once complete, you'll be reminded to commit the Changeset (which will be a unique
.mdfile in.changeset/), which you'll then push up to your PR.Note
changeset-botwill automatically detect Changesets (or the lack thereof) and comment on any PR containing them with info about the version bump and the contents of the Changelog entry.Releasing
The Changesets Release Action runs after every push to
master. It creates and maintains a PR which uses the Changeset files it finds to bump packages and updateCHANGELOG.mdfiles. Once merged, this PR will create appropriate tags for all updated packages & GitHub Releases for each tag.Publishing
To publish to npm, a maintainer will pull down the changes, then publish via
lerna publish from-packageorlaverna(depending; see "MAYBE TODO" below).TODO
An incomplete list of TODOs:
changeset-botto automatically nag contributors to create Changesets and display information about Changesets it detects. This requires it to be added to the Endo org, however.CONTRIBUTING.mdto reflect the new processes.MAYBE TODO
This work could be in this PR, or in a subsequent PR.
lernawith@lavamoat/laverna. Sincelernawill no longer handle versioning, it would only providelerna publish from-package... which happens to be exactly the thing@lavamoat/lavernaprovides. If we do this in a separate PR, we'll likely incur another change to the publishing workflow (even if slight). I could go either way on this.