Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add versioning notes to release.md #629

Merged
merged 7 commits into from
Jul 12, 2018
Merged
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 44 additions & 0 deletions release.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
# Versioning and Releases

Cirq is currently (as of July 11, 2018) alpha, and so has a MAJOR version
of 0. Below is info on how we version releases, and how the releases
themselves are created. Note that development is done on the `master`
branch, so if you want to use a more stable version you should use one
of the [releases](https://github.com/quantumlib/Cirq/releases) or
install from pypi.

## Versioning

We follow [semantic versioning](https://semver.org/) for labeling our
releases. Versions are labeled MAJOR.MINOR.PATCH where each of these
is a numerical value. The rules for versions changes are:
* Before MAJOR becomes 1, updates to MINOR can and will make changes to
public facing apis and interfaces..
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Double .

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

* After MAJOR becomes 1, updates that break the public facing api
or interface need to update MAJOR version.
* MINOR updates have to be backwards compatible (after MAJOR>=1).
* PATCH updates are for bug fixes.

## Releases

We use github's release system for creating releases. Release are listed
[on the Cirq release page](https://github.com/quantumlib/Cirq/releases).

Our development process uses the `master` branch for development.
When a release is made for a major or minor version update, `master`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say that a commit is tagged, not master.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed to "a commit to the master branch"

is tagged with a version tag (vX.X.X) for a pull request corresponding
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean by a pull request corresponding to the release? Like, we make a pull request "Release vX", merge it, and the resulting commit is what we tag?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ugh reworded

to the release. In the pull request corresponding to the release
the [version file](cirq/_version.py) should be updated. After
that version is cut, a future pull request should update the
version to the next minor version with `-dev` appended.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might want to do vX.X.X.dev instead to match what python tooling expects for package versions (see https://www.python.org/dev/peps/pep-0440/#public-version-identifiers). Or could leave the branch names with -dev but should also document what the package versions do.


For patch version updates (bug fixes), we follow a different pattern.
For these we create a separate branch that off of the version the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'that off of' gore

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

d

major minor version for the patch, or a previous branch patch. The
branches should be of the name `branch-X-X-X` corresponding to the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

double space

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

d

version. These can then be appropriately tagged and the release
pushed to pypi. These fixes, if possible, should also be merged
into master via a separate change.