Releasing
- Core
- Optional
- Tooling
Publishing to NPM
Releasing new builds of mithril to NPM is mostly automated via npm run release
- Update information in
docs/change-log.md
to match reality & the new version that will be released npm run release <major|minor|patch|semver>
All further steps are automated and run as follows:
- New bundles are generated using updated version
- Tests are run
- Linting is run (but doesn't fail build)
- Version number in package.json is incremented
git add
called on bundle outputpackage.json
and updated bundles are committed to git- previous commit is tagged using new version number
git push --follow-tags
pushes up new version commit & tag to github- Travis sees new release, starts build
- Travis generates new bundles before running tests
- Travis runs tests
- Travis lints files (but can't fail build)
- If build fails, abort
- Build succeeded, so travis will commit back any changes to the repo (but there won't be any)
- Travis sees that this commit has a tag associated with it
- Travis will use the encrypted npm creds in
.travis.yml
to publish a new version to npm
Publishing a GitHub release
Happens automatically as part of the Publishing to NPM process described above.
Does require a manual description to be added though, as the auto-generated one isn't very interesting. I suggest coming up with a fun title & then copying the docs/change-log.md
entry for the build.
Updating docs/change-log.md
This is still a manual process, I'm sorry.
Updating docs (outside of a new version)
Fixes to documentation can land whenever, updates to the site are published via Travis.
git co next
git pull lhorie next
git co master
git co next -- ./docs
- Ensure that no new features are added
git push lhorie
- After the Travis build completes new docs should appear in ~3 minutes
License: MIT. © Leo Horie.