-
-
Notifications
You must be signed in to change notification settings - Fork 527
docs: add docs for the release workflow #1590
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
@blocknote/ariakit
@blocknote/code-block
@blocknote/core
@blocknote/mantine
@blocknote/react
@blocknote/server-util
@blocknote/shadcn
@blocknote/xl-docx-exporter
@blocknote/xl-multi-column
@blocknote/xl-odt-exporter
@blocknote/xl-pdf-exporter
commit: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! see inline. Re your discussion points:
The CHANGELOG.md format, do we need it? Should we configure it, what should it include?
I think it's great as Release notes in github "lock us in" to github - so better to have this available directly in the git repo
Should GitHub Releases be done automatically?
Should we run tests before attempting to publish the package?
What should the process for a release be? Do we need a checklist?
Is this the right process? It is the easiest we can get away with nx right now, but should we think about doing other things like: release branches / github actions
I'd say it'd be great to have some stronger checks (e.g.: unit tests) automatically when doing a release, and maybe even make the workflow simpler with an Action button, but tbh I don't think it's worth optimizing this further at this moment. You've already streamlined the process a lot; let's go with this and learn+adapt as we go
Essentially, when the maintainers have decided to release a new version of BlockNote, they will: | ||
|
||
1. Check that the `main` branch is in a releasable state (i.e. all tests are passing, etc.) | ||
2. Bump the package versions using the `pnpm run deploy` command. This command will: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this also create the changelog?
|
||
Essentially, when the maintainers have decided to release a new version of BlockNote, they will: | ||
|
||
1. Check that the `main` branch is in a releasable state (i.e. all tests are passing, etc.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's make this a bit more actionable / checklist like. (e.g.: CI status of main branch must show a green checkmark)
This PR adds some documentation for how to make a BlockNote release. Let's also use this PR to discuss things like:
Is this the right process? It is the easiest we can get away with
nx
right now, but should we think about doing other things like: