-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Post 1.0 version policy and release process #5747
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
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| 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. | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -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
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
|
|
||
|
|
@@ -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
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
|
|
||
|
|
@@ -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 | ||
|
|
||
|
|
||
There was a problem hiding this comment.
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 )