{"action":"opened","issue":{"url":"https://api.github.com/repos/citusdata/citus/issues/2177","repository_url":"https://api.github.com/repos/citusdata/citus","labels_url":"https://api.github.com/repos/citusdata/citus/issues/2177/labels{/name}","comments_url":"https://api.github.com/repos/citusdata/citus/issues/2177/comments","events_url":"https://api.github.com/repos/citusdata/citus/issues/2177/events","html_url":"https://github.com/citusdata/citus/issues/2177","id":323901881,"number":2177,"title":"Release 7.2.2","user":{"login":"velioglu","id":10241593,"avatar_url":"https://avatars3.githubusercontent.com/u/10241593?v=4","gravatar_id":"","url":"https://api.github.com/users/velioglu","html_url":"https://github.com/velioglu","followers_url":"https://api.github.com/users/velioglu/followers","following_url":"https://api.github.com/users/velioglu/following{/other_user}","gists_url":"https://api.github.com/users/velioglu/gists{/gist_id}","starred_url":"https://api.github.com/users/velioglu/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/velioglu/subscriptions","organizations_url":"https://api.github.com/users/velioglu/orgs","repos_url":"https://api.github.com/users/velioglu/repos","events_url":"https://api.github.com/users/velioglu/events{/privacy}","received_events_url":"https://api.github.com/users/velioglu/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-05-17T07:25:52Z","updated_at":"2018-05-17T07:25:52Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"These instructions assume you have `$VERSION`, `$PROJECT`, and `$REPO` environment variables set in your shell (e.g. `7.2.0`, `citus`, and `citus`). With those set, code from most steps can be copy-pasted.\r\n\r\n**After this checklist, you're still not done: open a release checklist in Enterprise and release there, too!**\r\n\r\n# Prepare Project\r\n\r\n  - [ ] Ensure all needed changes are in the relevant `release-x.y` branch. `git log --cherry-pick --no-merges release-x.y...master` can be helpful. Be sure to cherry-pick changes in the same order they were _merged_ to the main branch (but do not cherry-pick merge commits themselves)\r\n  - [ ] Add a `CHANGELOG` entry in the `master` branch summarizing meaningful changes\r\n  - [ ] Use `git cherry-pick` to add the new `CHANGELOG` entry to the `release-x.y` branch\r\n  - [ ] Directly in the `release-x.y` branch, modify `configure.in` to reflect the new version\r\n  - [ ] Run `autoconf` to generate a new `configure` file and update the `SHOW citus.version` output in the `multi_extension` test\r\n  - [ ] Get _complete_ approval for the commit you're tagging before creating or pushing any tags. Tags should be immutable, so do **not** proceed to the next step until you're sure you have _everything_ you want in your release branch\r\n  - [ ] Use `git tag -a -s v$VERSION` to create an annotated, signed tag for the release. Summarize the release in the one-line tag annotation (beneath 52 characters). Push the tag with `git push origin v$VERSION`\r\n  - [ ] Visit the project's releases page (e.g. `open https://github.com/citusdata/$REPO/releases`)\r\n    - [ ] Create a new release object for your git tag (i.e. `v$VERSION`). Leave the description blank (it will auto-fill with the tag description)\r\n    - [ ] Click the _Source code (tar.gz)_ link for the new version to download a source tarball\r\n    - [ ] Sign the tarball using `gpg -a -u 3F95D6C6 -b $PROJECT-$VERSION.tar.gz`\r\n    - [ ] Back on the releases page, click the _Edit_ button for your release. Attach the signature (`$PROJECT-$VERSION.tar.gz.asc`) and click the _Update release_ button\r\n  - [ ] Re-create configuration and version files for next version\r\n    - [ ] Update configure.in by changing version number, keep the 'devel' suffix in 'AC_INIT' macro  and update the `SHOW citus.version` output in the `multi_extension` test\r\n    - [ ] Update configure.in and other config files (`autoconf && ./configure`)\r\n    - [ ] Add this changes only to the `master` branch\r\n\r\nIf you lack the signing key, it's in our 1Password vault. Ask around. As for signing tags, use your own key, and ensure it's [known to GitHub](https://help.github.com/articles/adding-a-new-gpg-key-to-your-github-account/).\r\n\r\n# Update OS Packages\r\n\r\n  - [ ] Check out the `debian-$PROJECT` branch of the [packaging repository](https://github.com/citusdata/packaging); create a new branch for your changes\r\n    - [ ] Add a new entry (`$VERSION.citus-1`, `stable`) to the `debian/changelog` file\r\n    - [ ] Update the `pkglatest` variable in the `pkgvars` file to `$VERSION.citus-1`\r\n    - [ ] Test the Debian release build locally: `citus_package -p=debian/jessie -p=debian/wheezy -p=debian/stretch -p=ubuntu/xenial -p=ubuntu/trusty local release 2>&1 | tee -a citus_package.log`\r\n    - [ ] Test the Debian nightly build locally: `citus_package -p=debian/jessie -p=debian/wheezy -p=debian/stretch -p=ubuntu/xenial -p=ubuntu/trusty local nightly 2>&1 | tee -a citus_package.log`\r\n    - [ ] Ensure no warnings or errors are present: `grep -Ei '(warning|\\bi|\\be|\\bw):' citus_package.log | sort | uniq -c`. Ignore any warnings about _using a gain-root-command while being root_ or _Recognised distributions_\r\n    - [ ] Push these changes to GitHub and open a pull request, noting any errors you found\r\n  - [ ] Check out the `redhat-$PROJECT` branch of the [packaging repository](https://github.com/citusdata/packaging); create a new branch for your changes\r\n    - [ ] Update the `pkglatest` variable in the `pkgvars` file to `$VERSION.citus-1`\r\n    - [ ] Edit the `$PROJECT.spec` file, being sure to:\r\n      - [ ] Update the `Version:` field\r\n      - [ ] Update the `Source0:` field\r\n      - [ ] Add a new entry (`$VERSION.citus-1`) to the `%changelog` section\r\n    - [ ] Test the Red Hat release build locally: `citus_package -p=el/7 -p=el/6 -p=fedora/26 -p=fedora/25 -p=ol/7 -p=ol/6 local release 2>&1 | tee -a citus_package.log`\r\n    - [ ] Test the Red Hat nightly build locally: `citus_package -p=el/7 -p=el/6 -p=fedora/26 -p=fedora/25 -p=ol/7 -p=ol/6 local nightly 2>&1 | tee -a citus_package.log`\r\n    - [ ] Ensure no warnings or errors are present: `grep -Ei '(warning|\\bi|\\be|\\bw):' citus_package.log | sort | uniq -c`. Ignore any errors about `--disable-dependency-tracking`\r\n    - [ ] Push these changes to GitHub and open a pull request\r\n  - [ ] Get changes reviewed; use the \"squash\" strategy to close the PR\r\n  - [ ] Ensure both Travis builds completed successfully (new releases should be in packagecloud)\r\n\r\n# Update Docker\r\n\r\n  - [ ] Create a `release-$VERSION` branch in your [docker repository checkout](https://github.com/citusdata/docker), based on `develop`\r\n  - [ ] If needed, bump the version of the base PostgreSQL image in the `FROM` instruction of the main `Dockerfile`\r\n  - [ ] Bump the Citus version number in the `Dockerfile` and `docker-compose.yml` files\r\n  - [ ] Add a new entry in the `CHANGELOG` noting that the Citus version has been bumped (and the PostgreSQL one, if applicable)\r\n  - [ ] Locally build your image and test it standalone and in a cluster: `docker build -t citusdata/citus:$VERSION .`\r\n  - [ ] Open _two_ pull request: one against `develop`, and one against `master`. Get one or the other reviewed, and merge both. You can do it by copying your branch with another name and opening a PR to the remaining base.\r\n  - [ ] Tag the latest `master` as `v$VERSION`: `git fetch && git tag -a -s v$VERSION origin/master && git push origin v$VERSION`\r\n  - [ ] Ensure the Docker Hub builds (e.g. https://hub.docker.com/r/citusdata/citus/builds) complete successfully\r\n\r\n# Update CloudFormation\r\n\r\n  - [ ] Check out the `master` branch of the [cloudformation repository](https://github.com/citusdata/cloudformation)\r\n  - [ ] Update the two places in `citus-7/citusdb.json` which reference the Citus version (search and replace)\r\n  - [ ] Commit and push to GitHub\r\n  - [ ] Upload the template as `citus-$VERSION.json` to S3 (in the folder `citus-deployment/aws/citus7/cloudformation`)\r\n\r\n# Update Documentation\r\n\r\n  - [ ] Check out the `master` branch of the [documentation repository](https://github.com/citusdata/citus_docs)\r\n  - [ ] Bump version occurrences in `conf.py` and `installation/multi_machine_aws.rst`\r\n  - [ ] Open a Pull Request\r\n\r\n# Update PGXN\r\n\r\n  - [ ] Check out the `pgxn-$PROJECT` branch of the [packaging repository](https://github.com/citusdata/packaging)\r\n  - [ ] Bump all version occurrences in `META.json`\r\n  - [ ] Bump all version occurrences in `pkgvars`\r\n  - [ ] Test locally with `citus_package -p=pgxn local release`\r\n  - [ ] Push these changes to GitHub and open a pull request\r\n  - [ ] After merging, ensure the Travis build completed successfully (a new release should appear in PGXN eventually)\r\n\r\n# Update PGDG\r\n\r\nPGDG has separate teams for Red Hat and Debian builds.\r\n\r\n## Red Hat\r\n\r\n  - [ ] Create a new feature request in [the RPM Redmine](https://redmine.postgresql.org/projects/pgrpms/issues/new) asking their team to update the Citus version in their spec file\r\n  - [ ] Wait for the issue to be closed and verify that the package is available in the PGDG RPM repo\r\n\r\n## Debian\r\n\r\n  - [ ] Check out the `debian` branch of the [packaging repository](https://github.com/citusdata/packaging)\r\n  - [ ] Add a new entry (`$VERSION.PGDG-1`, `unstable`) to the `debian/changelog` file\r\n  - [ ] Commit this change and push to GitHub\r\n  - [ ] Visit the PGDG Jenkins [page for Citus](https://pgdgbuild.dus.dg-i.net/job/citus-source/) and click the _Build with Parameters_ link\r\n  - [ ] Leave all parameters as default and press the _Build_ button\r\n  - [ ] After success, the `citus-binaries` project will build. When it's done, the next `dput` task will upload the build artifacts to [testing](https://wiki.postgresql.org/wiki/Apt/FAQ#What_are_the_testing_distributions.3F)\r\n  - [ ] Verify the package works, then [open an issue](https://redmine.postgresql.org/projects/pgapt/issues/new) to have it promoted from `testing`\r\n\r\nThe PGDG Jenkins site uses client-side certificates for login, which is a bit obnoxious to manage. If you don't have a certificate for logging in, [follow these instructions](https://wiki.postgresql.org/wiki/Apt/Jenkins#Jenkins_Login)."}}
{"actor":{"display_login":"velioglu"}}