2016-04-29 08:00:03 -04:00
# Releasing a new OSRM version
2016-08-03 07:29:11 -04:00
We are using http://semver.org/ for versioning with major, minor and patch versions.
2016-04-29 08:00:03 -04:00
2016-08-03 07:29:11 -04:00
## Guarantees
2016-05-03 17:36:14 -04:00
2016-08-03 07:29:11 -04:00
We are giving the following guarantees between versions:
2016-05-03 17:36:14 -04:00
2016-08-03 07:29:11 -04:00
### Major version change
2016-05-03 17:36:14 -04:00
2016-08-03 07:29:11 -04:00
- There are no guarantees about compatiblity of APIs or datasets
- Breaking changes will be noted as `BREAKING` in the changelog
2016-05-03 17:36:14 -04:00
2016-08-03 07:29:11 -04:00
### Minor version change
2016-05-03 17:36:14 -04:00
2016-08-03 07:29:11 -04:00
We may introduce forward-compatible changes: query parameters and response properties may be added in responses, but existing properties may not be changed or removed. One exception to this is the addition of new turn types, which we see as forward-compatible changes.
2016-05-03 17:36:14 -04:00
2016-08-03 07:29:11 -04:00
- Forward-compatible HTTP API
- Forward-compatible C++ library API
- Forward-compatible node-osrm API
- No compatiblity between OSRM datasets (needs new processing)
2016-05-03 17:36:14 -04:00
2016-08-03 07:29:11 -04:00
### Patch version change
2016-05-03 17:36:14 -04:00
2016-08-03 07:29:11 -04:00
- No change of query parameters or response formats
- Compatible HTTP API
- Compatible C++ library API
- Compatible node-osrm API
- Compatible OSRM datasets
2016-05-03 17:36:14 -04:00
2016-08-03 07:29:11 -04:00
## Release and branch management
2016-04-29 08:00:03 -04:00
2016-08-03 07:29:11 -04:00
- The `master` branch is for the bleeding edge development
2016-08-05 12:03:42 -04:00
- We create and maintain release branches `x.y` to control the release flow
2016-11-14 18:21:19 -05:00
- We create the release branch once we tagged the final version `x.y.0` version, RCs go on master
2016-08-03 07:29:11 -04:00
- 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
- Patch versions may be released without a release candidate
- We may backport fixes to older versions and release them as patch versions
2016-04-29 08:00:03 -04:00
2016-08-03 07:29:11 -04:00
## Releasing a version
2016-08-05 11:59:22 -04:00
1. Check out the appropriate release branch `x.y`
2016-08-03 07:29:11 -04:00
2. Make sure all tests are passing (e.g. Travis CI gives you a :thumbs_up:)
3. Make sure `CHANGELOG.md` is up to date.
2016-04-29 08:00:03 -04:00
4. Make sure the OSRM version in `CMakeLists.txt` 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.
6. Push tags and commits: `git push; git push --tags`
2016-08-03 07:29:11 -04:00
8. Proceede with the `node-osrm` release as [outlined in the repository ](https://github.com/Project-OSRM/node-osrm/blob/master/docs/releasing.md ).
9. If not a release-candidate: Write a mailing-list post to osrm-talk@openstreetmap.org to announce the release
2016-08-05 12:03:42 -04:00