Open-Harbor/osrm-backend
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 3 Wiki Activity

Update releasing docs

Browse Source
This commit is contained in:
Patrick Niklaus 2017-03-29 16:35:48 +00:00 committed by Patrick Niklaus
parent d200507424
commit 0363d64722
1 changed files with 13 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
docs/releasing.md
View File

@ -32,21 +32,25 @@ We may introduce forward-compatible changes: query parameters and response prope
- The `master` branch is for the bleeding edge development - The `master` branch is for the bleeding edge development
- We create and maintain release branches `x.y` to control the release flow - We create and maintain release branches `x.y` to control the release flow
- We create the release branch once we tagged the final version `x.y.0` version, RCs go on master - We create the release branch once we create release branches once we want to release the first RC
- RCs go in the release branch, commits needs to be cherry-picked from master
- No minor or major version will be released without a code-equal release candidates - No minor or major version will be released without a code-equal release candidates
- For quality assurance, release candidates will be run on the demo server for 24 hours before releaseing the version proper - For quality assurance, release candidates need to be staged beforing tagging a final release
- Patch versions may be released without a release candidate - Patch versions may be released without a release candidate
- We may backport fixes to older versions and release them as patch versions - We may backport fixes to older versions and release them as patch versions
## Releasing a version ## Releasing a version
1. Check out the appropriate release branch `x.y` 1. Check out the appropriate release branch `x.y`
2. Make sure all tests are passing (e.g. Travis CI gives you a :thumbs_up:) 2. Make sure `CHANGELOG.md` is up to date.
3. Make sure `CHANGELOG.md` is up to date. 3. Make sure the OSRM version in `CMakeLists.txt` is up to date
4. Make sure the OSRM version in `CMakeLists.txt` is up to date 4. Make sure the `package.json` is up to date.
5. Use an annotated tag to mark the release: `git tag vx.y.z -a` Body of the tag description should be the changelog entries. 5. Make sure all tests are passing (e.g. Travis CI gives you a :thumbs_up:)
6. Use `npm run build-api-docs` to generate the API documentation. Copy `build/docs/*` to `https://github.com/Project-OSRM/project-osrm.github.com` in the `docs/vN.N.N/api` directory 6. Use an annotated tag to mark the release: `git tag vx.y.z -a` Body of the tag description should be the changelog entries.
6. Push tags and commits: `git push; git push --tags` 7. Use `npm run build-api-docs` to generate the API documentation. Copy `build/docs/*` to `https://github.com/Project-OSRM/project-osrm.github.com` in the `docs/vN.N.N/api` directory
8. Proceede with the `node-osrm` release as [outlined in the repository](https://github.com/Project-OSRM/node-osrm/blob/master/docs/releasing.md). 8. Push tags and commits: `git push; git push --tags`
9. If not a release-candidate: Write a mailing-list post to osrm-talk@openstreetmap.org to announce the release 9. If not a release-candidate: Write a mailing-list post to osrm-talk@openstreetmap.org to announce the release
10. Wait until the travis build has been complated and check if the node binaries were published by doing:
`rm -rf node_modules && npm install` locally.
11. For final releases run `npm publish` or `npm publish --tag next` for release candidates.