Home

Creating a new release

1. Ensure that:

   • The version number has been incremented in Main.java, build.gradle, release.yml, and all other locations it appears before attempting to merge into master. See the RCTab versioning page to determine what version number you should use.
   • The JDK version has been updated in GitHub actions (e.g. test.yml, release.yml, etc.) to match the JDK used during development.

2. Create a PR merging develop into master and gather all necessary approvals.

3. Merge the PR using "Create a merge commit" (i.e. DO NOT SQUASH AND MERGE)

   • Note: As of 2020-12-12, our repo has "Create a merge commit" disabled, so you'll need to temporarily enable "Allow merge commits" in the general settings and then disable it again once the merge is done).

4. Create a pre-release using GitHub, making sure to check the "Set as a pre-release" option that the tag name follows the proper versioning format (e.g. v1.3.1). Save a draft first, and then publish that draft.

   • Note: there's no need to create a tag directly on the branch using git; you can type the branch name directly in the input on GitHub and click "create new tag on publish".
   • After publishing the pre-release, this action will automatically create zips of the compiled code for Linux, Mac, and Windows (as well as SHA files for checksum verification), and attach them to the release as assets.

5. Download each of the three zip files (Linux, Mac, and Windows) and test them on each platform, making sure to actually run tabulations using the data in the sample_input folder.

6. After verifying that all three builds are working as intended, convert the pre-release into a release.

7. Merge master back into develop to avoid potential conflicts in the future. This can either be done by:

   • (Preferred) Creating a PR and getting it approved, or
   • Temporarily removing "Require a pull request before merging" on develop in the branch settings, merging master into develop locally, and pushing to develop directly.

8. Restore any repo settings that might have been modified during this process (e.g. disable "Allow merge commits" again, re-enable "Require a pull request before merging" on develop, etc.).

Creating a hotfix release

1. Create a branch off master and apply the hotfix in there.
2. Follow all the steps in the "Creating a new release" section, with the following changes:
   • The initial PR created should merge the hotfix branch into master.
   • When merging master back into develop (which will bring in the hotfix), use "Create a merge commit" if going the PR route.

Generating list of all error messages

• bash/ag: find all logger.[info,warning,severe]: for type in "info" "warning" "severe"; do ag --nofilename --multiline --ignore src/test "Logger[ ]*.[ ]*$type\([^)]*\);" > logger.$type.txt; done
• vim: remove start-of-line whitespace: VG50<
• vim: remove CRLF. :%s/\r//g
• vim: remove double-newlines: :%s/\n\n/\r/g
• vim: merge multiline logs: :%s/\([^;]\)\n/\1/g
• vim: remove broken-up strings from multiline logs: :%s/"[^"]*+[^"]"//g
• vim: clean up (replace Logger.info with just info:): :%s/Logger.\([a-z]*\)(\(.*\));/\1: \2
• vim: remove triple quotes: :%s/"""/"/g
• Manually add in all calls to logErrorWithLocation, which on last inspection, was:
  • severe: "%s must be an integer equal to %d for file source %s", fieldName, lowerBoundary, inputLocation
  • severe: "%s must be an integer from %d to %d for file source %s", fieldName, lowerBoundary, upperBoundary, inputLocation
  • severe: "%s must be an integer equal to %d if supplied for file source %s", fieldName, lowerBoundary, inputLocation
  • severe: "%s must be an integer from %d to %d if supplied for file source %s", fieldName, lowerBoundary, upperBoundary, inputLocation
  • severe: "%s should not be defined for CVR source with provider "%s" for file source %s", fieldName, provider, inputLocation
  • severe: "treatBlankAsUndeclaredWriteIn should not be true for CVR source with provider "%s"for file source %s", fieldName, provider, inputLocation