-
-
Notifications
You must be signed in to change notification settings - Fork 8.7k
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
chore: add prerelease script #876
Changes from 4 commits
e2e8180
35cc1dc
449f252
dd46a49
7e7ffa6
059a3de
11fa2db
6279e74
785cb81
e87969a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,15 @@ | ||
# Prereleasing New Version of Docusaurus | ||
|
||
[![asciicast](https://asciinema.org/a/n8rm53yfNURlIreGJkdSTgfAi.png)](https://asciinema.org/a/n8rm53yfNURlIreGJkdSTgfAi) | ||
|
||
# Steps | ||
|
||
1. Ensure that `origin` remote is your Docusaurus fork. Example | ||
|
||
```bash | ||
$ git remote -v | ||
origin https://github.com/endiliey/Docusaurus.git (fetch) | ||
origin https://github.com/endiliey/Docusaurus.git (push) | ||
``` | ||
|
||
2. Run `bash scripts/prerelease.sh` to create a pull request for release of new version. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,47 @@ | ||
#!/bin/bash | ||
|
||
echo "Select an option for release:" | ||
echo | ||
|
||
select VERSION in patch minor major "Specific Version" | ||
do | ||
echo | ||
if [[ $REPLY =~ ^[1-4]$ ]]; then | ||
if [[ $REPLY == 4 ]]; then | ||
read -p "Enter a specific version: " -r VERSION | ||
echo | ||
if [[ -z $REPLY ]]; then | ||
VERSION=$REPLY | ||
fi | ||
fi | ||
|
||
read -p "Release $VERSION - are you sure? (y/n) " -n 1 -r | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think |
||
echo | ||
|
||
if [[ $REPLY =~ ^[Yy]$ || -z $REPLY ]]; then | ||
# bump version | ||
yarn version --new-version $VERSION --no-git-tag-version | ||
NEW_VERSION=$(node -p "require('./package.json').version") | ||
|
||
# create new branch | ||
git checkout -b $NEW_VERSION master | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we should create new branch before bumping version just to be safe. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I did this because I wanted to get the new version (after bump) as the branch name. How about naming it to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Mm gotcha. Let's leave this as it is. On second thought it's fine because we're not committing yet. |
||
|
||
# cut docusaurus docs version | ||
cd website && yarn run version $NEW_VERSION | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Omg we should probably rename this command within There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Will There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sounds good. Will need to update a few places as well. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually i wanted to rework all the CLI commands to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh yes we should do that, but not now. I fully agree with you (wrote about that in v2 under API) also. |
||
|
||
# Create PR | ||
echo "Creating Pull Request for Release ${NEW_VERSION}" | ||
git add . | ||
git commit -m "v$NEW_VERSION" | ||
git push origin $NEW_VERSION | ||
echo "✅ Release PR created" | ||
else | ||
echo Cancelled | ||
fi | ||
break | ||
else | ||
echo Invalid \"${REPLY}\" | ||
echo "To continue, please enter one of the options (1-4):" | ||
echo | ||
fi | ||
done |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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