Release Process

This page documents our development and release flows.

Release Process

The ciao project will have a nightly release.

Nightly release versions will be an incrementing integer and not semantic based.

At a specified time, the head commit of the master branch will be tested with a set of basic acceptance tests. These tests are distributed in the ciao source code under the "_release" directory. If the tests pass, the master branch will be tagged at the commit with release tag and released via github releases.

The release notes are generated from the list of github issues closed, github pull requests merged, and commits. Because of this it is imperative that issues, pull requests, and commits have informative descriptions.

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.

If a pull request is submitted for early feedback and it is not yet ready for merging, it should be marked [DO NOT MERGE] at the start of the subject line.

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.
7. Ensure that the pull request description is informative.