Cut_a_release

The QA release procedure is inspired by the ISCE3 Release Procedure. QA is a separate repo from ISCE3, but they are developed (and usually released) in tandem with each other, so the procedures are similar.

---

QA follows semantic versioning, so our internal versioning scheme does not necessarily line up with our named deliverables for the NISAR project. (Early QA releases did not adhere well to this system; versioning stabilized starting with R3.2.)

QA Git tag	NISAR Delivery	Notable features (highlights)
v1.0.0	Unknown
v1.1.0-ER	R1.1 ER
R2	R2
v2.0.0	R3.2	Fresh rewrite. RSLC QA: Browse+basic report
v3.0.0	R3.3	GSLC QA: Browse+basic report. Color SLC browse
v3.0.1	R3.3-patch1
v4.0.0	R3.3 mid-cycle	GCOV QA: Browse+basic report
v5.0.0	R3.4	RIFG/RUNW/GUNW QA: Browse+basic reports, Product Readers
v5.0.1	R3.4-patch1	bugfix
v6.0.0	R3.4.1	AbsCal and PTA Caltools, ROFF/GOFF Quiver plots
v6.0.1	R3.4.1-patch1	bugfix
v7.0.0	R4.0-prelim	Range spectra plots, logger, InSAR plots
v7.0.1	R4.0-prelim-patch1	bugfix
v8.0.0	R4	InSAR Plots, XML Checker, Summary CSV
v9.0.0	R4.0.2-beta.1	Connected Components, PTA plots, InSAR metrics
v10.0.0	R4.0.2-preview	pyproject.toml, XML Checker updates, Az Spectra plots in RSLC
v11.0.0	R4.0.2	Metadata cube checks
v12.0.0	R4.0.4	Add'l file validation checks, InSAR Histograms. Move to Public GitHub.
v13.0.0	R4.0.6	Minor Updates after transition to Public Github

Release Procedure

Before the release:

All development is merged into the main branch.

Creating the release branch

• If the release is a major release, push a commit to the main branch updating __version__ = ... to the next major version, resetting the minor and patch version numbers to 0. (This is located in src/nisarqa/__init__.py.) Otherwise, skip this step.
• Starting on the main branch, create a new release branch from the latest commit. Release branches are named release-v<version>, where <version> is the current version number, excluding the patch number. For example, if the current version is "0.2.0", the release branch will be named release-v0.2. Push the new branch to the upstream remote.
  • git checkout -b release-v0.2
  • git push upstream release-v0.2
• Back on the main branch, push a commit updating __version__ = ... to the next minor version, resetting the patch version to 0. (This is located in src/nisarqa/__init__.py.)
  • "0.2.0" -> "0.3.0"
  • Note: No need to create a PR for this simple change in QA.

Creating the tagged release

Now, we need to tag and publish the release to GitHub.

• On the release-v0.2 branch, create a tag and push the tag:
  • git tag v0.2.0
  • git push upstream v0.2.0
• Go to the releases tab on GitHub and click Draft a new release
  • Release Title should be e.g. "R3.3" or "R3.3-patch1"
  • Hint: Click the "Generate release notes" button

Update ISCE3 with the new QA release

Due to NISAR Operations needs, deliveries of ISCE3 should pull the latest version of QA while building their Docker images.

• Update+commit ISCE3 runconfig defaults and schema with any changes from QA.
  • ISCE3 Defaults for NISAR operations: defaults
  • ISCE3 Schemas: schemas
• Update+commit ISCE3's Dockerfile with new tagged release version of QA:
  • ISCE3 Dockerfile: dockerfile
• Update+commit any changes to the L1/L2 workflow test runconfigs I - ISCE3 Workflow Tests runconfigs: test runconfigs

Patching a release

If the patch applies to both main and the release branch:

• Using the standard branch+PR process, commit+merge the code changes into main. Do not update __version__ during this step.
• Checkout the existing release branch:
  • git checkout release-v0.2
• Cherry-pick the patch commit(s) to the release branch. The changes will now be on both the primary development branch (main) and in the release branch.
• On the release branch, push a commit updating __version__ = ... to the next patch version. (This is located in src/nisarqa/__init__.py.)
  • "0.2.0" -> "0.2.1"
• Follow the "Creating a Tagged Release" instructions above, but using the updated version and patch numbers.