@david-waltermire, per our desire to coordinate a patch release with NIST, can we please target this PR on main, not develop? I will ping you in an upcoming discussion topic. Thanks!

That would be fine with me (main not develop) although I just stated the opposite (over on #2069) - shows what I know.

As for the merits of the PR, 👍 to backward-compatible improvements and corrections - if the constraint is to be included at all it should be correct. (Removing it into a different layer of constraint checking is also a good solution in my view.)

According to the contributing guidelines it looks like I should target release-1.1 for a patch release. I am going to rebase and change the PR to point there.

According to the contributing guidelines it looks like I should target release-1.1 for a patch release. I am going to rebase and change the PR to point there.

This is correct and everything we merged already in develop was staged for the v1.1.3 patch release, hence the request to submit the PRs towards develop branch, so we do not need to rebase develop to release 1.1.3. There are no new features or models added, but dependency updates are also a needed. There is one SAP constraints bug #2059 that must be also fixed with the v1.1.3. Once we decide the direction to go for #2059, will implement it, asap, test it and release 1.1.3.

According to the contributing guidelines it looks like I should target release-1.1 for a patch release. I am going to rebase and change the PR to point there.

This is correct and everything we merged already in develop was staged for the v1.1.3 patch release, hence the request to submit the PRs towards develop branch, so we do not need to rebase develop to release 1.1.3. There are no new features or models added, but dependency updates are also a needed. There is one SAP constraints bug #2059 that must be also fixed with the v1.1.3. Once we decide the direction to go for #2059, will implement it, asap, test it and release 1.1.3.

I am happy to rebase to develop if that is what you want me to do.

I do want to point out that what you are suggesting is not consistent with the practices for a patch release identified in the contributing guidelines for the repository which states:

Contributions can be made to the following branches in this repository:

• release-*: The release branches are used to provide patches to a major or minor version of OSCAL. The branches are named release-major.minor. You should provide changes only to the highest numbered minor release for a given major release. Patch releases are made more frequently than major or minor releases.
• develop: This branch is used to queue changes for the next major/minor release of OSCAL. A major/minor release will result in the creation of a new release branch, once the development has been completed and the update is to be staged for release.

Inconsistent application of these guidelines makes the process confusing, difficult to predict, and more labor intensive for contributors. It would be helpful to have a more consistent approach.