chore: add prerelease script #876
Conversation
|
Deploy preview for docusaurus-preview ready! Built with commit e87969a |
There was a problem hiding this comment.
This is great!
A couple of comments:
-
Does this presume that we will still update the
.lockfiles automatically? -- there is an outstanding question whether we should have.lockfiles at all. -
We could extend this to start the Changelog updates for us too, maybe? 😄
admin/prerelease.md
Outdated
|
|
||
| # Steps | ||
|
|
||
| 1. Ensure that `origin` remote is your Docusaurus fork. Example |
There was a problem hiding this comment.
Before executing any of these steps, we will have to make the changes in the CHANGELOG, etc, is that right? If so, we should add it before this step.
There was a problem hiding this comment.
Yes we had to make changes in CHANGELOG, etc as well.
However, for CHANGELOG I propose that we now start adding changelog everytime we merge PR just like how jest do it. This will make it easier for our process.
Example:
A recently closed PR in jest https://github.com/facebook/jest/pull/6776/files has a changelog commit as well
Then we will always have a changelog for master version
There was a problem hiding this comment.
I'm not opposed to trying that but feel that it's hard for Docusaurus PR submitters to write the CHANGELOG. We'll need to create a template for the next version and pending PRs would always have to take note of which section of CHANGELOG they're updating. Might be a source of frequent merge conflicts. @JoelMarcey thoughts?
There was a problem hiding this comment.
Alternatively, the person who merge the PR should update the changelog just right before merging it.
So PR submitter doesn't have to do it
scripts/prerelease.sh
Outdated
| fi | ||
| fi | ||
|
|
||
| read -p "Release $VERSION - are you sure? (y/n) " -n 1 -r |
There was a problem hiding this comment.
I think "Submit a PR for a bump in $VERSION version - Are you sure ..." is clearer.
| NEW_VERSION=$(node -p "require('./package.json').version") | ||
|
|
||
| # create new branch | ||
| git checkout -b $NEW_VERSION master |
There was a problem hiding this comment.
I think we should create new branch before bumping version just to be safe.
There was a problem hiding this comment.
I did this because I wanted to get the new version (after bump) as the branch name. How about naming it to prerelease ? We can also delete the existing local prerelease branch as well before creating new branch
There was a problem hiding this comment.
Mm gotcha. Let's leave this as it is. On second thought it's fine because we're not committing yet.
scripts/prerelease.sh
Outdated
| git checkout -b $NEW_VERSION master | ||
|
|
||
| # cut docusaurus docs version | ||
| cd website && yarn run version $NEW_VERSION |
There was a problem hiding this comment.
Omg we should probably rename this command within website/package.json. It's easy to confuse with yarn's native version command.
There was a problem hiding this comment.
Will docsversion do?
There was a problem hiding this comment.
Sounds good. Will need to update a few places as well.
There was a problem hiding this comment.
Actually i wanted to rework all the CLI commands to docusaurus <command> instead of docusaurus-command but this might lead to breaking changes.
There was a problem hiding this comment.
Oh yes we should do that, but not now. I fully agree with you (wrote about that in v2 under API) also.
|
Note that this doesn't really update CHANGELOG.md or other files automatically. I have updated the instruction and the asciinema preview to show that you have to update CHANGELOG & other files. |
|
Awesome. I am looking forward to one of us trying this. |
Motivation
Simplify maintainer process before releasing new version
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
Click this asciinema preview
https://asciinema.org/a/hZ7NNJPcgtdvzm5tMLLfHflMD