vndb/mithril-vndb
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update release docs

Browse source
This commit is contained in:
James Forbes 2022-03-12 19:58:03 +11:00 • committed by Stephan Hoyer
parent 931e475de2
commit f3c59665b1
2 changed files with 22 additions and 364 deletions
Download patch file Download diff file Expand all files Collapse all files

104
docs/releasing.md
View file

@ -4,102 +4,40 @@ Describes how we do releases of Mithril.js
# Mithril.js Release Processes
**Note** These steps all assume that `MithrilJS/mithril.js` is a git remote named `mithriljs`, adjust accordingly if that doesn't match your setup.
Mithril's release process is automated by [pr-release]. pr-release is maintained by a long time mithril.js community member [@JAForbes](https://github.com/JAForbes).
- [Releasing a new Mithril.js version](#releasing-a-new-mithriljs-version)
- [Updating mithril.js.org](#updating-mithriljsorg)
pr-release handles the following:
## Releasing a new Mithril.js version
- Generating changelog entries
- Automating the semver version
- Publishing releases and pre-releases to npm
- Creating github releases
- Rollbacks
### Prepare the release
## For contributors
1. Ensure your local branch is up to date
Contributors should create their feature branch targetting the default branch `next`. When this branch is merged `pr-release` will either generate or update a release PR from `next` to `main`.
```bash
$ git checkout next
$ git pull --rebase mithriljs next
```
The description and title will be managed by [pr-release], including the semver version.
2. Determine patch level of the change
3. Update information in `docs/changelog.md` to match reality of the new version being prepared for release.
- Don't forget to add today's date under the version heading!
4. Replace all existing references to `mithril@next` to `mithril` if moving from a release candidate to stable.
- Note: if making an initial release candidate, don't forget to move all the playground snippets to pull from `mithril@next`!
5. Commit changes to `next`
Contributors who have permissions should add the correct semver label to their PR (`major` | `minor` | `patch`). If no label is set, `patch` is assumed.
```
$ git add .
$ git commit -m "Preparing for release"
If you do not have permissions, the maintainer will set the label on your behalf.
# Push to your branch
$ git push
## Changelog
# Push to MithrilJS/mithril.js
$ git push mithriljs next
```
There are two changelogs in the mithril project
### Merge from `next` to `master`
- `docs/changelog.md` a hand written curated reflection of changes to the codebase
- `docs/release.md` an automatically prepended log of changes, managed by pr-release
6. Switch to `master` and make sure it's up to date
In future we may collapse these into a single file, the separation is due to the fact the `changelog.md` predates the `release.md` file.
```bash
$ git checkout master
$ git pull --rebase mithriljs master
```
## For maintainers
7. merge `next` on top of it
Whenever a new feature branch is opened, a reviewing maintainer should add the correct semver label to their PR (`major` | `minor` | `patch`). If no label is set, `patch` is assumed.
```bash
$ git merge next
```
8. Clean & update npm dependencies and ensure the tests are passing.
```bash
$ npm prune
$ npm i
$ npm test
```
### Publish the release
9. `npm run release <major|minor|patch|semver>`, see the docs for [`npm version`](https://docs.npmjs.com/cli/version)
10. The changes will be automatically pushed to your fork
11. Push the changes to `MithrilJS/mithril.js`
```bash
$ git push mithriljs master
```
12. Travis will push the new release to npm & create a GitHub release
### Merge `master` back into `next`
This helps to ensure that the `version` field of `package.json` doesn't get out of date.
13. Switch to `next` and make sure it's up to date
```bash
$ git checkout next
$ git pull --rebase mithriljs next
```
14. Merge `master` back onto `next`
```bash
$ git merge master
```
15. Push the changes to your fork & `MithrilJS/mithril.js`
```bash
$ git push
$ git push mithriljs next
```
### Update the GitHub release
16. The GitHub Release will require a manual description & title to be added. I suggest coming up with a fun title & then copying the `docs/changelog.md` entry for the build.
If a `major` or `minor` feature branch is merge, but no labels were set, you can go back and apply the labels and then re-run the `pr` workflow in github actions, this will recalculate the semver version.
## Updating mithril.js.org
@ -124,3 +62,5 @@ $ node scripts/update-docs
After the docs build completes, the updated docs should appear on https://mithril.js.org in a few minutes.
**Note:** When updating the stable version with a release candidate out, ***make sure to update the index + navigation to point to the new stable version!!!***
[pr-release]: https://pr-release.org/