Skip to content

Home

Jump to bottom
HEdingfield edited this page Nov 9, 2023 · 10 revisions

RCTab versioning

  • Development release versions should always end in *.999
    • E.g.: if we're currently at version 1.3.1, then the development version leading up to the next new version should be called 1.3.999 (no matter if the next version will be 1.3.2, 1.4.0, or 2.0.0)
    • E.g.: similarly, if we're currently at version 2.0.0, the development version for the next release should be 2.0.999 regardless of what the next version will be (2.0.1, 2.1.0, or 3.0.0)
  • Production release versions should never end in *.999

That means that the develop branch should, in general, end in *.999, and the master branch should, in general, not. There may be reasonable exceptions to this.

Note: This replaces a past convention of adding -alpha, -beta, etc. after the new version number. See PR #719 for full discussion.

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.
    • 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
Clone this wiki locally