Release 1.6.3

[DimCitus]

These instructions assume you have $VERSION, $PROJECT, and $REPO environment variables set in your shell (e.g. 1.4, pgautofailover, and pg_auto_failover). With those set, code from most steps can be copy-pasted.

Prepare Project

• [x] 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)
• [x] Add a CHANGELOG entry in the master release-x.y branch summarizing meaningful changes ( will merge release branch into master after releasing to update the changelog there )
• [x] Update vendored in libraries under src/bin/lib. Verify README.md has a reference to each library in the folder.
  • [x] PG : Compare the contents of snprintf.h , snprintf.c and strerror.c in folder src/bin/lib/pg against PG equivalents in recent PG sources under src/port and apply changes to respective places.
  • [x] Parson : Compare the contents of src/bin/lib/parson vs the source from https://github.com/kgabis/parson
  • [x] ini.h: Compare src/bin/lib/libs/ini.h vs source at https://github.com/mattiasgustavsson/libs. Apply changes.
  • [x] log.c: Compare contents of src/bin/lib/log vs its source from https://github.com/rxi/log.c . Apply changes as necessary
• [x] Update version number in
  • [x] src/bin/pg_autoctl/defaults.h
  • [x] docs/conf.py
  • [x] Makefile
  • [x] src/bin/pg_autoctl/azure.c
• [x] 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
• [x] 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
• [x] Visit the project's releases page (e.g. open https://github.com/citusdata/$REPO/releases)
  • [x] 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)

As for signing tags, use your own key, and ensure it's known to GitHub.

Update OS Packages

• [ ] Make sure you have the latest tooling installed from the https://github.com/citusdata/tools repo, using (sudo) make install
• [ ] Go to your locally checked out version of the https://github.com/citusdata/packaging repo.
• [ ] Create a packaging PR using update_os_package.pl all pgautofailover $VERSION
• [ ] Test the release build locally: citus_package -p=debian/buster -p=debian/stretch -p=ubuntu/bionic -p=ubuntu/xenial -p ubuntu/focal -p=el/8 -p=el/7 -p=ol/7 local release 2>&1 | tee citus_package.log
• [ ] Confirm for some of the packages that the contents look decent using dpkg -c package.deb and rpm -qlp package.rpm
• [ ] Ensure no warnings or errors are present: grep -Ei '(warning|\bi|\be|\bw):' citus_package.log | sort | uniq -c | grep -v "\.c". Ignore any errors about --disable-dependency-tracking
• [ ] Get changes reviewed;
• [ ] Confirm that CI is happy
• [ ] Use the "squash" strategy to close the PR
• [ ] Ensure both Travis builds completed successfully (new releases should be in packagecloud, you should expect 52 items when searching for new version)

[rheaton]

Hi @DimCitus - We were looking into pulling this in to our next release for the bug fixes, but noticed the new command and build dependency. Do you think this is worthy of a minor bump or separating the bug fixes & new command?

Thanks, Rachel

[DimCitus]

Hi @DimCitus - We were looking into pulling this in to our next release for the bug fixes, but noticed the new command and build dependency. Do you think this is worthy of a minor bump or separating the bug fixes & new command?

Hi @rheaton ; I feel like it's okay to have both in the same minor release. There are two reasons for backing that up: first, we have a short list of changes, so the risk area isn't big. Second, the new command is client-side only, doesn't require restarting anything, and you could just never use it too if you wanted. Also the new build dependency is on the ncurses lib, which has been around everywhere since the 90s I believe, and is the basis of so many widely available tools that I can't imagine it causing havoc.