Release Process

This page documents our development and release flows. It is WIP - and contains loose notes to begin formalizing how we will work.

Release Process

The ciao project will have a nightly release.

Nightly release versions will be datetime and not semantic based. We may in the future decide to do some semantic releases on a difference cadence, such as a once a month stable release.

At a specified time, the head commit of the master branch will be tested. If the tests pass, the master branch will be tagged at the commit with release tag and automatically do the release.

This can be automated using the releases API: https://developer.github.com/v3/repos/releases/#create-a-release

Or with something like this: http://www.rubydoc.info/gems/github-release/0.1.3

Because we are going to be doing fully automated test/release, we need to autogenerate release notes. The release notes can contain a changelog as well as the results of the QA tests. If you want images, such as a graph, you can use image links, but we’d need to host the images somewhere. We would love to have graphs showing metrics of the nightly releases, but that would seem to require a custom website.

Merging and Reviewing

Because the ciao master must always be ready to release, we will push pull requests only on master. Our master branch is “protected” so that a pull request is required to pass all status checks before it can be merged.

There are 2 gatekeepers for master who can merge pull requests after the required checks have passed: one in Europe and one in the US. Gatekeepers rotate every 2 weeks.

Gatekeeper schedule

Additionally, each component has it’s own gatekeeper who is required to review the code for their component prior to merging.

Package maintainers

The master gatekeeper can chose to review or not. The master gatekeeper may also assign other people to review and require that review prior to merging.

If it’s your own code for your own component and you’re the master gatekeeper, it’d be best if the other gatekeeper reviewed and merged it.

Merge checklist

In order for a pull request to be merged, all the status checks must pass. In addition, the following manual checks should be made.

1. All the patches have a SOB (we could automate this and make it a travis check if we wanted to)
2. The patches were reviewed by the component owner at least
3. Did the change introduce any new 3rd party dependencies?

• Verify that the license is compatible.
• Verify that the package meets our standards for quality and security.
• Ensure that the package is vendored.

4. Does the pull request require any documentation changes either for architecture or usage?
5. Any new functionality must have a unit test. Test coverage must not be lowered by the pull request.
6. Make sure any new files have an appropriate copyright notice.