This should help point users to the correct version if they plan to install the release candidate, and it should help users find the existing docs for v1.
4.1 KiB
4.1 KiB
Mithril 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.
Releasing a new Mithril version
Prepare the release
- Ensure your local branch is up to date
$ git checkout next
$ git pull --rebase mithriljs next
- Determine patch level of the change
- Update information in
docs/change-log.mdto match reality of the new version being prepared for release - Replace all existing references to
mithril@nexttomithrilif moving from a release candidate to stable. - Commit changes to
next
$ git add .
$ git commit -m "Preparing for release"
# Push to your branch
$ git push
# Push to MithrilJS/mithril.js
$ git push mithriljs next
Merge from next to master
- Switch to
masterand make sure it's up to date
$ git checkout master
$ git pull --rebase mithriljs master
- merge
nexton top of it
$ git merge next
- Clean & update npm dependencies and ensure the tests are passing.
$ npm prune
$ npm i
$ npm test
Publish the release
npm run release <major|minor|patch|semver>, see the docs fornpm version- The changes will be automatically pushed to your fork
- Push the changes to
MithrilJS/mithril.js
$ git push mithriljs master
- 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.
- Switch to
nextand make sure it's up to date
$ git checkout next
$ git pull --rebase mithriljs next
- Merge
masterback ontonext
$ git merge master
- Push the changes to your fork &
MithrilJS/mithril.js
$ git push
$ git push mithriljs next
Update the GitHub release
- The GitHub Release will require a manual description & title to be added. I suggest coming up with a fun title & then copying the
docs/change-log.mdentry for the build.
Updating mithril.js.org
Fixes to documentation can land whenever, updates to the site are published via Travis.
# These steps assume that MithrilJS/mithril.js is a git remote named "mithriljs"
# Ensure your next branch is up to date
$ git checkout next
$ git pull mithriljs next
# Splat the docs folder from next onto master
$ git checkout master
$ git checkout next -- ./docs
# Manually ensure that no new feature docs were added
$ git push mithriljs
After the Travis 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!!!
Releasing a new ospec version
- Ensure your local branch is up to date
$ git checkout next
$ git pull --rebase mithriljs next
- Determine patch level of the change
- Update
versionfield inospec/package.jsonto match new version being prepared for release - Commit changes to
next
$ git add .
$ git commit -m "chore(ospec): ospec@<version>"
# Push to your branch
$ git push
# Push to MithrilJS/mithril.js
$ git push mithriljs next
Merge from next to master
- Switch to
masterand make sure it's up to date
$ git checkout master
$ git pull --rebase mithriljs master
- merge
nexton top of it
$ git checkout next -- ./ospec
$ git add .
$ git commit -m "chore(ospec): ospec@<version>"
- Ensure the tests are passing!
Publish the release
- Push the changes to
MithrilJS/mithril.js
$ git push mithriljs master
- Publish the changes to npm from the
/ospecfolder. That bit is important to ensure you don't accidentally ship a new Mithril release!
$ cd ./ospec
$ npm publish