docs: updated releasing workflow
This commit is contained in:
parent
a6bb1d4651
commit
87a053224c
1 changed files with 34 additions and 21 deletions
|
|
@ -1,36 +1,49 @@
|
|||
# Releasing
|
||||
|
||||
Releasing new builds of mithril is mostly automated via `npm version`
|
||||
|
||||
## Publishing to NPM
|
||||
|
||||
1. `npm run release <major|minor|patch|semver>`
|
||||
Releasing new builds of mithril to NPM is mostly automated via `npm run release`
|
||||
|
||||
1. Update information in `docs/change-log.md` to match reality & the new version that will be released
|
||||
2. `npm run release <major|minor|patch|semver>`
|
||||
|
||||
All further steps are automated and run as follows:
|
||||
|
||||
2. New bundles are generated using updated version
|
||||
3. Tests are run
|
||||
4. Linting is run (but doesn't fail build)
|
||||
5. Version number in package.json is incremented
|
||||
6. `git add` called on bundle output
|
||||
7. `package.json` and updated bundles are committed to git
|
||||
8. previous commit is tagged using new version number
|
||||
9. `git push --follow-tags` pushes up new version commit & tag to github
|
||||
10. Travis sees new release, starts build
|
||||
11. Travis generates new bundles before running tests
|
||||
12. Travis runs tests
|
||||
13. Travis lints files (but can't fail build)
|
||||
14. If build fails, abort
|
||||
15. Build succeeded, so travis will commit back any changes to the repo (but there won't be any)
|
||||
16. Travis sees that this commit has a tag associated with it
|
||||
17. Travis will use the encrypted npm creds in `.travis.yml` to publish a new version to npm
|
||||
3. New bundles are generated using updated version
|
||||
4. Tests are run
|
||||
5. Linting is run (but doesn't fail build)
|
||||
6. Version number in package.json is incremented
|
||||
7. `git add` called on bundle output
|
||||
8. `package.json` and updated bundles are committed to git
|
||||
9. previous commit is tagged using new version number
|
||||
10. `git push --follow-tags` pushes up new version commit & tag to github
|
||||
11. Travis sees new release, starts build
|
||||
12. Travis generates new bundles before running tests
|
||||
13. Travis runs tests
|
||||
14. Travis lints files (but can't fail build)
|
||||
15. If build fails, abort
|
||||
16. Build succeeded, so travis will commit back any changes to the repo (but there won't be any)
|
||||
17. Travis sees that this commit has a tag associated with it
|
||||
18. 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](#publishing-to-npm) process described above.
|
||||
|
||||
Does require a manual description to be added though, as the auto-generated one isn't very interesting.
|
||||
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`
|
||||
|
||||
**TODO**
|
||||
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.
|
||||
|
||||
1. `git co next`
|
||||
2. `git pull lhorie next`
|
||||
3. `git co master`
|
||||
4. `git co next -- ./docs`
|
||||
5. Ensure that no new features are added
|
||||
6. `git push lhorie`
|
||||
7. After the Travis build completes new docs should appear in ~3 minutes
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue