Eel Baseline Version Bump to v1

[mdueltgen]

🗣 Description

Bumping version number to be ready for Eel release and be consitent with ScubaGear

💭 Motivation and context

Closes #632

🧪 Testing

N/A

✅ Pre-approval checklist

• This PR has an informative and human-readable title.
• Changes are limited to a single goal - eschew scope creep!
• If applicable, All future TODOs are captured in issues, which are referenced in the PR description.
• The relevant issues PR resolves are linked preferably via closing keywords.
• All relevant type-of-change labels have been added.
• I have read and agree to the CONTRIBUTING.md document.
• These code changes follow cisagov code standards.
• All relevant repo and/or project documentation has been updated to reflect the changes in this PR.
• Tests have been added and/or modified to cover the changes in this PR.
• All new and existing tests pass.

✅ Pre-merge Checklist

• This PR has been smoke tested to ensure main is in a functional state when this PR is merged.
• Squash all commits into one PR level commit using the Squash and merge button.

✅ Post-merge Checklist

• Delete the branch to clean up.
• Close issues resolved by this PR if the closing keywords did not activate.

[snarve]

The updates in the baselines and the drift rules look good, however this will require code changes as well. The current change breaks the code. Do we plan to address that in this issue itself or will create a separate issue that will need a quick fix to avoid breaking code changes.
The breaking change is due to the format change in the version numbering from v0.4.x to v1 (code expects .separated version number)

[rlxdev]

I quickly updated this to include the minor version, which is still what we want to do, right?

[snarve]

I quickly updated this to include the minor version, which is still what we want to do, right?

Post v1, the baseline numbering will be different, which means each baseline number will be updated only if the baseline has been updated (there are restrictions on this as well, meaning which updates call for a change in the numbering). This is to be consistent with ScubaGear/M365 Baselines.

So, say Chat policy CHAT.1.1v1 if updated and requires a numbering update, will become CHAT.1.1v1.1. However, CHAT.1.2v1 will remain unchanged if there are no updates.

[rlxdev]

So, if we're at a "major" version release, the baselines get no minor version number, but if they happen to change during a "point" release, they get a major and minor version number? This will require code changes (not major), but I'm wondering what the benefit is to having some baselines v1, v2, v3, and v1.3, v2.5, and not v1.0, v1.1, v1.2.

[adhilto]

So, if we're at a "major" version release, the baselines get no minor version number, but if they happen to change during a "point" release, they get a major and minor version number? This will require code changes (not major), but I'm wondering what the benefit is to having some baselines v1, v2, v3, and v1.3, v2.5, and not v1.0, v1.1, v1.2.

Actually, the control versions will never have minor versions. So in the example @snarve gave, the new version would be GWS.CHAT.1.1v2.

For example:

• ScubaGear: current version is 1.5.0.
• MS.EXO.1.1v1 is still in its original form.
• MS.EXO.2.2v2 has been updated once.