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

docs: updated releasing workflow

Browse source
This commit is contained in:
Pat Cavit 2017-03-27 15:24:36 -07:00
parent a6bb1d4651
commit 87a053224c
1 changed files with 34 additions and 21 deletions
Download patch file Download diff file Expand all files Collapse all files

55
docs/releasing.md
View file

@ -1,36 +1,49 @@
# Releasing # Releasing
Releasing new builds of mithril is mostly automated via `npm version`
## Publishing to NPM ## 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: All further steps are automated and run as follows:
2. New bundles are generated using updated version 3. New bundles are generated using updated version
3. Tests are run 4. Tests are run
4. Linting is run (but doesn't fail build) 5. Linting is run (but doesn't fail build)
5. Version number in package.json is incremented 6. Version number in package.json is incremented
6. `git add` called on bundle output 7. `git add` called on bundle output
7. `package.json` and updated bundles are committed to git 8. `package.json` and updated bundles are committed to git
8. previous commit is tagged using new version number 9. previous commit is tagged using new version number
9. `git push --follow-tags` pushes up new version commit & tag to github 10. `git push --follow-tags` pushes up new version commit & tag to github
10. Travis sees new release, starts build 11. Travis sees new release, starts build
11. Travis generates new bundles before running tests 12. Travis generates new bundles before running tests
12. Travis runs tests 13. Travis runs tests
13. Travis lints files (but can't fail build) 14. Travis lints files (but can't fail build)
14. If build fails, abort 15. If build fails, abort
15. Build succeeded, so travis will commit back any changes to the repo (but there won't be any) 16. 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 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 18. Travis will use the encrypted npm creds in `.travis.yml` to publish a new version to npm
## Publishing a GitHub release ## Publishing a GitHub release
Happens automatically as part of the [Publishing to NPM](#publishing-to-npm) process described above. 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` ## 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