Contributor license agreement (CLA)¶
When you contribute code, you affirm that the contribution is your original work and that you license the work to the project under the project’s open source license. Whether or not you state this explicitly, by submitting any copyrighted material via pull request, email, or other means you agree to license the material under the project’s open source license and warrant that you have the legal authority to do so.
Please make sure you have signed our Contributor License Agreement (either Individual Contributor License Agreement v1.0 or Software Grant and Corporate Contributor License Agreement (“Agreement”) v1.0).
We are not asking you to assign copyright to us, but to give us the right to distribute your code without restriction. We ask this of all contributors in order to assure our users of the origin and continuing existence of the code. You only need to sign the CLA once.
GE core team members use this checklist to ship releases.
If this is a major release (incrementing either the first or second version number) the manual acceptance testing must be completed.
This private google doc outlines the procedure. (Note this will be made public eventually)
Merge all approved PRs into
Make a new branch from
developcalled something like
In this branch, update the version number in the
changelog.rst: move all things under
developunder a new heading with the new release number.
Verify that any changes to requirements are specifically identified in the changelog
Double check the grouping / order of changes matches [BREAKING], [FEATURE], [ENHANCEMENT], [BUGFIX], [DOCS], [MAINTENANCE] and that all changes since the last release are mentioned or summarized in a bullet.
Make sure to shout out community contributions in the changelog! E.g. after the change title add
Submit this as a PR against
After successful checks, get it approved and merged.
Update your local branches and switch to main:
git fetch --all; git checkout main; git pull.
Merge the now-updated
mainand trigger the release:
git merge origin/develop; git push
Wait for all the builds to complete. The builds should include several test jobs and a deploy job, which handles the actual publishing of code to pypi. You can watch the progress of these builds on Azure.
Check PyPI for the new release
Create an annotated git tag:
git tag -a <<VERSION>> -m "<<VERSION>>"with the correct new version.
Push the tag up by running
git push origin <<VERSION>>with the correct new version.
developso that the tagged commit becomes part of the history for
git checkout develop; git pull; git merge main
On develop, add a new “develop” section header to changelog.rst, and push the updated file with message “Update changelog for develop”
Create the release on GitHub with the version number. Copy the changelog notes into the release notes, and update any rst-specific links to use github issue numbers.
The deploy step will automatically create a draft for the release.
Generally, we use the name of the tag (Ex: “0.11.2”) as the release title.
Notify firstname.lastname@example.org about any community-contributed PRs that should be celebrated.
Socialize the release on GE slack by copying the changelog with an optional nice personal message (thank people if you can)
Review the automatically-generated PR for conda-forge (https://github.com/conda-forge/great-expectations-feedstock/pulls), updating requirements as necessary and verifying the build status.
Beta Release Notes
To ship a beta release, follow the above checklist, but use the branch name
v0.11.xas the equivalent of
v0.11.x-developas the equivalent of
Ship the release using beta version numbers when updating the
great_expectations/deployment_versionand when creating the annotated tag (e.g. 0.11.0b0)