Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(deps): add support for OSCAL 1.1.3 as default #837

Merged
merged 4 commits into from
Dec 6, 2024

Conversation

brandtkeller
Copy link
Member

@brandtkeller brandtkeller commented Dec 4, 2024

Description

Switches to the new go-oscal OSCAL 1.1.3 types

quick find-and-replace for oscalTypes_1_1_2 switching to oscalTypes to prevent necessary modification in the future.

We have future issues to address the use of non-latest OSCAL versions and evaluation of what that means for go-oscal and Lula.

Tested the upgrade/lint workflow to ensure they operated accordingly.

How to test these changes manually

  • Confirm build without issues
  • Search repository for "github.com/defenseunicorns/go-oscal/src/types/oscal-1-1-2"
    • No matches should exist
  • Search repository for "oscalTypes_1_1_2"
    • No matches should exist
  • Tests passing

Related Issue

Fixes #834

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Other (security config, docs update, etc)

Checklist before merging

@brandtkeller brandtkeller self-assigned this Dec 4, 2024
@brandtkeller brandtkeller requested a review from a team as a code owner December 4, 2024 23:18
@meganwolf0
Copy link
Collaborator

We used to just do like "oscalTypes" (or something similar, I don't recall) instead of "oscalTypes_1_1_2" - just trying to make sure we're not losing some intent for that original change to more specific version of oscal?

@brandtkeller
Copy link
Member Author

We used to just do like "oscalTypes" (or something similar, I don't recall) instead of "oscalTypes_1_1_2" - just trying to make sure we're not losing some intent for that original change to more specific version of oscal?

I don't believe we are regressing on any decision made. I believe oscalTypes_x_x_x was the initial pattern and we've been iterating towards oscalTypes.

Given a more concrete stance today (Lula really only supports a single version of OSCAL + and upgrade workflow to get you to the operational version) - I believe this doesn't impact anything and we still have some exploration to-do.

@brandtkeller brandtkeller merged commit 255e8ff into main Dec 6, 2024
10 checks passed
@brandtkeller brandtkeller deleted the 834_oscal_113_update branch December 6, 2024 17:46
@meganwolf0
Copy link
Collaborator

Had to go wayy back to figure out what I was thinking about
CleanShot 2024-12-06 at 13 30 24

But yeah fair enough, I just thought I recalled that change and didn't have context at the time cuz I was brand new, but sounds like maybe just a thing that changed and not a thing that changed for a reason

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: ✅ Done
Development

Successfully merging this pull request may close these issues.

Default to OSCAL version 1.1.3
3 participants