Skip to content
Merged
Show file tree
Hide file tree
Changes from 1 commit
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
3 changes: 3 additions & 0 deletions cirq-google/version_policy.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
# cirq-google Version Policy

The `cirq-google` directory will mostly abide by Semantic Versioning 2.0.0. In rare cases, we may introduce backward-incompatible changes to the public API in a release with a minor version increment. Such changes will be noted in `CHANGELOG.md` within the directory before the release.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Instead of "will mostly", "should" might be clearer (following https://datatracker.ietf.org/doc/html/rfc2119 )

55 changes: 46 additions & 9 deletions release.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,15 +12,46 @@ latest commit to master can be installed with `pip install --pre cirq`.

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.
* 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.

Versions based on unreleased branches of master will be suffixed with ".dev".
is a numerical value. The following guarantees are provided:

1. All packages released at the same time from the Cirq repository will share
the same [Semantic Versioning 2.0.0](https://semver.org/) number.
1. Packages may have different version numbers in the future, at which point
this policy will be updated.
2. Libraries in the `cirq-core` directory (with the exception of
`cirq-core/cirq/contrib`) adhere to the guarantees outlined in the Semantic
Versioning specification. In summary: “Bug fixes not affecting the API
increment the patch version, backwards compatible API additions/changes
increment the minor version, and backwards incompatible API changes increment
the major version.”
3. The contrib directory (at `cirq-core/cirq/contrib`) follows Semantic
Versioning except the MINOR version increment policy: releases with MINOR
version increments may contain backward-incompatible functionality changes to
its public API.
1. May be changed to strictly follow Semantic Versioning in the future, at
which point this policy will be updated.
4. Cirq vendor directories (`cirq-aqt`, `cirq-google`, `cirq-ionq`, etc.) follow
Semantic Versioning except the MINOR version increment policy: each vendor
directory has a separate policy on whether MINOR version increments provide
backward-compatibility guarantees, as described in `version_policy.md` in the
respective directory.
1. If `version_policy.md` does not exist in a particular vendor directory,
MINOR version increments may contain backward-incompatible functionality
changes to its public API.
2. For each vendor directory, version policies may be modified to strictly
follow Semantic Versioning in the future.
Comment on lines +33 to +42
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

So, if I understand correctly, the version of the vendor packages will still track the version of cirq-core, right?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Thanks for your review! Yes that's right.

5. Versions based on unreleased branches of master will be suffixed with ".dev".

The rules for version changes are:
* Increment the PATCH version if all changes are bug fixes only.
* Increment the MINOR version if changes contain functionalities which are
backward-compatible, or if a vendor directory or `contrib` contains
backward-incompatible changes and the policy for the directory allows
backward-incompatible changes for a minor version increment.

A major version increment process has not been established. Until then,
backward-incompatible changes are not allowed for `cirq-core` and vendor
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I might be nit picking but "should not be allowed" feels more accurate absent an enforcement mechanism

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

I'm not sure about this one - IMO a released backward-breaking change which is discovered later should be considered a bug and be fixed in a subsequent release. Although an enforcement mechanism such as CI is a lot more accurate than enforcement through maintainer reviews, any system could have bugs that let some breaking changes through, and I think the stronger "are not allowed" should be used when either of the two mechanisms are in place.

WDYT?

directories that prohibit them for a minor version increment.

## Releases

Expand All @@ -34,6 +65,10 @@ in a release branch with a version tag (vX.X.X). Then, master will be updated
to the next minor version. This can always be found in the
[version file](cirq/_version.py).

### Release Schedule
Releases are made on an as-needed basis determined by Cirq maintainers. All Cirq
packages (including vendor packages such as `cirq-aqt`) are released at the same
time.
Comment on lines +69 to +71
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I'm ok with this approach, though it is unclear how things would unfold should a vendor package require an urgent patch because it seems that cirq-core dictates the release schedule. I agree it should be a rare event, but I would still like to see it documented in the "one-off process" you mentioned above.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Agree that this process needs to be documented. I have a proposal (in short, making a minor version release branch when a patch is necessary) but it still needs to be discussed with a wider audience. Because this is rare, the plan is to defer the discussion to unblock releasing the version policy.


## Before you release: flush the deprecation backlog

Expand Down Expand Up @@ -192,6 +227,8 @@ checking the history of the init files. `git diff <previous version>..HEAD cirq-
You can get the contributing authors for the release by running:
`git log <previous version>..HEAD --pretty="%an" | sort | uniq | sed ':a;N;$!ba;s/\n/, /g'`

### cirq-google Changelog
Add cirq-google release notes to `cirq-google/CHANGELOG.md` following the [changelog format](https://keepachangelog.com/en/1.0.0/)

### Release to prod pypi

Expand Down