28 Nov 20:05

github-actions

612d884

v4.7.1

What's Changed

Add platform host-based unit tests and code coverage @Javagedes (#729)
Change Details
## Description
Adds a PlatformTest.py per platform package which:
1. self verifies the platform host-based unit test dsc is up to date (no new hosted-based test INFs have been added locally or from a submodule that test source used by the platform).
2. Compiles the host-based unit tests.
3. Executes the host-based unit tests.
4. Optionally generates code coverage data.
Adds additional pipeline jobs to run the host-based tests and generate code coverage information.
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

CI

Integration Instructions

CI

Cargo.toml: Optimize dev profile binary size @makubacki (#767)
Change Details
## Description
By default, the dev profile is used. The default build settings for the dev profile are documented here:
https://doc.rust-lang.org/cargo/reference/profiles.html#dev

Unmodified dev profile settings result in extraordinarily large binaries relative to UEFI FW. This especially impacts DEBUG builds which already have less optimized C code resulting in overall greater space occupation.

Without a change, the binaries are simply too large and will continue to push the limits of firmware volumes (on a real system constrained by flash size) over time.

Therefore, the below setting enables optimization level 3 (all optimizations) that is used by the release profile by default. This greatly reduces the overall binary size. [profile.dev.package."*"] is specified to apply the opt-level for all dependencies (but not a workspace member). This emphasizes debuggability of workspace code but optimizes dependencies. An individual dependency can be overridden by specifying the named package instead of "*". For example:
```
[profile.dev.package.foo]
opt-level = 0
```
That will likely allow the overall build to still fit in the FV, since other code is still optimized, but remove optimizations from an individual package that needs to be debugged.
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested
- Verified build size of several config combinations (including the chosen one).
  - [profile.dev] opt-level = 'z'
    
    DXE FV: 11643648 (0xb1ab00) used (size opt of all packages)
  - [profile.dev.package."*"] opt-level = 'z'
    
    DXE FV: 12365056 (0xbcad00) used (size opt of dependencies)
  - [profile.dev.package."*"] opt-level = 3
    
    DXE FV: 12431104 (0xbdaf00) used (level 3 opt of dependencies)
Integration Instructions

N/A - Affects packages built in this workspace

🐛 Bug Fixes

VirtualDriveManager: Fix incremental usage on Linux @makubacki (#780)
Change Details
## Description
Currently, FlashRomImage() in PlatformBuild.py checks if the
virtual drive file (VirtualDrive.img) exists. If so, make_drive()
is not called which is the only function that currently sets the
MTOOLSRC environment variable to the mtool.conf file path which
is consumed by mtools.

Typical mtool.conf file contents as used in VirtualDriveManager:
```
  drive+ a:
    file="/w/m/Build/QemuSbsaPkg/DEBUG_GCC5/VirtualDrive.img" exclusive
```
This means if VirtualDrive.img already exists (i.e. on an
incremental Linux build with the VIRTUAL_DRIVE parameter present),
the MTOOLSRC variable is not available to mtools resulting in the
following error:
```
  INFO - Can't open /dev/fd0: No such file or directory
  INFO - Cannot initialize 'A:'
  INFO - Bad target a:
```
This change sets MTOOLSRC on incremental builds so the existing
virtual drive can be used.

A separate commit also removes trailing whitespace from VirtualDriveManager.py
since there is a lot throughout the file.
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested
- With VIRTUAL_DRIVE parameter given:
  - Linux build with VirtualDrive.img missing (clean build)
  - Linux build with VirtualDrive.img present (incremental build)
    
    Previously failed
  - Linux build with VirtualDrive.img present and mtool.conf missing
    
    Unexpected state but possible
Integration Instructions

N/A

🛠️ Submodule Updates

Bump Silicon/Arm/MU\_TIANO from 2023020000.1.2 to 2023020000.1.3 @ProjectMuBot (#781)
Change Details
Bumps Silicon/Arm/MU_TIANO from `2023020000.1.2` to `2023020000.1.3`
Introduces 5 new commits in Silicon/Arm/MU_TIANO.
Commits
- fb39b5 GitHub Action: Bump actions/github-script from 6 to 7 (#180)
- 4ece5b Repo File Sync: synced file(s) with microsoft/mu_devops (#177)
- fa3856 Integration steps for mu_devops@9.0.1: Add Code coverage (#181)
- f58b70 ArmPkg/Drivers/CpuDxe: Use lower and upper attributes
- e42172 ArmPkg/Drivers/CpuD...

Contributors

makubacki, Javagedes, and ProjectMuBot

Assets 7

31 Oct 15:34

github-actions

v4.6.1

081cfd8

v4.6.1

What's Changed

Add rust-ci scope to Qemu35Pkg and QemuSbsaPkg @makubacki (#745)
Change Details
## Description
Add this scope so Rust related CI plugins run since the packages are
already building Rust code.
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested
- Verified CI builds with the scope set
Integration Instructions

N/A - Affects plugins run in this repo

🛠️ Submodule Updates

Bump Common/MU from 2023020002.1.0 to 2023020003.0.0 @ProjectMuBot (#753)
Change Details
Bumps Common/MU from `2023020002.1.0` to `2023020003.0.0`
Introduces 3 new commits in Common/MU.
Commits
- b93bb2 Update HelloWorldRustDxe to permit compiling for unit tests (#341)
- 0c488d Repo File Sync: Include Rust Env Exclusions in CodeQL Workflow (#344)
- dc3ab8 Add PCD to allow device exclusions for UsbHidDxe (#340)
Signed-off-by: Project Mu Bot mubot@microsoft.com

Bump MU\_BASECORE from 2023020007.1.3 to 2023020007.2.0 @ProjectMuBot (#752)
Change Details
Bumps MU_BASECORE from `2023020007.1.3` to `2023020007.2.0`
Introduces 4 new commits in MU_BASECORE.
Commits
- 963f6b BaseTools/Plugin: Add Rust Environment Check build plugin (#600)
- aec07a pip: update edk2-pytool-extensions requirement from ~=0.25.0 to ~=0.25.1 (#601)
- 135f26 BaseTools/Plugin: Add tool exclusion to RustEnvironmentCheck (#602)
- 6f4fd1 Repo File Sync: Include Rust Env Exclusions in CodeQL Workflow (#603)
Signed-off-by: Project Mu Bot mubot@microsoft.com

Bump MU\_BASECORE from 2023020007.1.2 to 2023020007.1.3 [Rebase \& FF] @ProjectMuBot (#749)
Change Details
Bumps MU_BASECORE from `2023020007.1.2` to `2023020007.1.3`
Introduces 2 new commits in MU_BASECORE.
Commits
- 1f32c2 MdeModulePkg and UefiCpuPkg CodeQL Fixes (#561)
- 461a59 EsrtFmp CodeQL Fix (#598)
Signed-off-by: Project Mu Bot mubot@microsoft.com

Full Changelog: v4.6.0...v4.6.1

Contributors

makubacki and ProjectMuBot

Assets 7

23 Oct 17:55

github-actions

v4.6.0

14e7eff

v4.6.0

What's Changed

Note: Mouse support on Q35 was found to be broken (based on local testing) for
a while, covering at least several releases. It is verified to be functional in this release
(using the Rust based HID driver stack).

🚀 Features & ✨ Enhancements

QemuQ35Pkg: Update memory type information defaults [Rebase \& FF] @makubacki (#739)
Change Details
## Description
QemuQ35Pkg: Update memory type information defaults

Updates the default values for PcdMemoryTypeEfiACPIReclaimMemory
and PcdMemoryTypeEfiReservedMemoryType to prevent a runtime
adjustment to the memory bucket sizes.

Based on the values calculated including buffer:
```
  Memory  Previous  Current   Minimum    Next
   Type    Pages     Pages     Pages     Pages
  ======  ========  ========  ========  =======
    0A    00000080  00000026  00000000  00000080
    09    00000010  00000012  00000000  00000016*
    00    00000080  0000040D  00000000  00000510*
    05    00000100  000000AF  00000000  00000100
    06    00000100  00000100  00000000  00000100
  Memory Type Information settings change.
```
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested
- QemuQ35Pkg build and boot
Integration Instructions

N/A

Integrate Rust HID driver @makubacki (#738)
Change Details
## Description
Per integration instructions in microsoft/mu_plus#324,
UsbMouseAbsolutePointerDxe is removed and UsbHidDxe and UefiHidDxe are
added to the build.

The absolute pointer protocol will now be installed by the AbsolutePointer
crate in HidPkg linked against the UefiHidDxe module.
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested
- Verified QemuQ35Pkg and QemuSbsaPkg build and boot to EFI shell
Integration Instructions

N/A

📖 Documentation Updates

Docs/Common/Featues: Add Front Page Instructions @makubacki (#742)
Change Details
## Description
Since there's a couple build variables that can influence which front
page is built and how it is loaded, this change updates the currently
empty front page feature document to include the relevant build
variable information.
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

CI build including markdownlint.

Integration Instructions

N/A

🛠️ Submodule Updates

Bump Features/CONFIG from 2.0.5 to 2.0.6 @ProjectMuBot (#747)
Change Details
Bumps Features/CONFIG from `2.0.5` to `2.0.6`
Introduces 6 new commits in Features/CONFIG.
Commits
- 392d21 pip: bump edk2-pytool-library from 0.18.2 to 0.19.0 (#261)
- 1f6d76 pip: bump edk2-pytool-extensions from 0.24.1 to 0.25.0 (#262)
- 04e6f1 Repo File Sync: Update to Mu DevOps v7.0.0 (#260)
- d40247 Add the default in switch implementation to prevent gcc build error (#263)
- c91a9f Repo File Sync: Update to Mu DevOps 7.0.1 (#264)
- decdc3 pip: bump edk2-pytool-library from 0.19.0 to 0.19.1 (#265)
Signed-off-by: Project Mu Bot mubot@microsoft.com

Bump MU\_BASECORE from 2023020007.1.1 to 2023020007.1.2 @ProjectMuBot (#746)
Change Details
Bumps MU_BASECORE from `2023020007.1.1` to `2023020007.1.2`
Introduces 1 new commits in MU_BASECORE.
Commits
- cf73dc [PolicyServicePkg] Adding MemoryAllocationLib to library classes that rely on it (#597)
Signed-off-by: Project Mu Bot mubot@microsoft.com

Bump Common/MU from 2023020002.0.4 to 2023020002.1.0 @ProjectMuBot (#744)
Change Details
Bumps Common/MU from `2023020002.0.4` to `2023020002.1.0`
Introduces 1 new commits in Common/MU.
Commits
- 310592 UefiHidDxe...

Contributors

makubacki and ProjectMuBot

Assets 7

22 Sep 23:40

github-actions

v4.5.2

11462b9

v4.5.2

What's Changed

Update MU\_BASECORE, Remove VariablePolicyFuncTestApp Test Exemption @TaylorBeebe (#708)
Change Details
## Description
VariablePolicyFuncTestApp now passes on Q35 and SBSA.
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

Tested in the CI pipelines

Integration Instructions

N/A

🛠️ Submodule Updates

Bump MU\_BASECORE from 2023020006.2.1 to 2023020006.2.2 @ProjectMuBot (#704)
Change Details
Bumps MU_BASECORE from `2023020006.2.1` to `2023020006.2.2`
Introduces 1 new commits in MU_BASECORE.
Commits
- 4a6dc6 Added Ipmi Threshold sensor APIs and their NULL implementation (#564)
Signed-off-by: Project Mu Bot mubot@microsoft.com

Full Changelog: v4.5.1...v4.5.2

Contributors

TaylorBeebe and ProjectMuBot

Assets 7

07 Sep 23:32

github-actions

v4.5.0

1731ed3

v4.5.0

What's Changed

🚀 Features & ✨ Enhancements

Add CodeQL Filtering and GitHub Workflow Support [Rebase \& FF] @makubacki (#692)
Change Details
## Description
CodeQL was previously enabled in the repo to the point that it could
be run locally with the --codeql flag. It was not enabled in CI
because the pre-existing CodeQL GitHub workflow did not support platform
builds.

This change hooks PlatformBuild.py into the newer stuart_codeql helper
functionality, adds proper filtering support, and a platform workflow that
allows CodeQL to run in this repo on every PR.

Running CodeQL at a "platform" level is advantageous because it can catch
similar CodeQL violations found when building physical platform code.

Note: codeql-platform.yml is directly checked into the repo here as it has
been tested and it is more clearly explained attached to this PR. In the
future, it will be synced from mu_devops.
There is some similarity with the pre-existing CodeQL CI workflow but those
are relatively simple tasks not expected to change much and may be converged
in the future but that is not a goal right now.

Note: CodeQL is only enabled for QemuQ35Pkg as the CodeQL extractor fails
on Linux for edk2 style builds and QemuSbsaPkg does not build on Windows/
Visual Studio at this time.

pip: bump edk2-pytool-extensions from 0.24.0 to 0.24.1

Includes the edk2toolext.codeql functions needed in upcoming
changes.

QemuQ35Pkg/PlatformBuild.py: Add CodeQL filtering support

Makes a number of adjustments in PlatformBuild.py as outlined below.
The main improvement is adding support to recursively gather CodeQL
filter files within the repo.
1. Remove unused imports at the top of the file.
2. Use the CodeQL functions newly added to edk2-pytool-extensions.
3. Replace local functionality with common implementation in the
  codeql module.
4. Remove trailing whitespace throughout the file.
Add CodeQL platform GitHub workflow

Adds a new GitHub workflow that allows CodeQL to run against platform
builds. Previously, only a "CI" CodeQL workflow existed that did not
support platform builders.

This file is being added directly to the repo as it is paired with
other changes that it has been tested alongside. In the future, it
will automatically be synced from mu_devops.

Nothing about the file is specific to mu_tiano_platforms or any
particular platform. It works by discovering all buildable platforms
in a repo before any dependencies are cloned and then verifying
the build files in the platform package directory support platform
build. If they do, it is checked if they support CodeQL. Only
platforms that meet all of these conditions are actually built via
a dynamic platform package matrix.

This allows the workflow to scale across platform repos and
automatically pick up new platforms as they onboard support for
CodeQL.
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested
1. Ran the QemuQ35Pkg CodeQL build locally
2. Ran the CodeQL - Platform GitHub workflow
  - Verified successful detection and build of QemuQ35Pkg
Integration Instructions

Moving forward, it is recommended to run CodeQL locally when making C source
code changes in QemuQ35Pkg. Also, CodeQL success will become a required
status check in mu_tiano_platforms CI for QemuQ35Pkg. See the following
CodeQL plugin documentation for more info.

🛠️ Submodule Updates

Bump Common/MU\_TIANO from 2023020000.0.4 to 2023020000.1.0 @ProjectMuBot (#697)
Change Details
Bumps Common/MU_TIANO from `2023020000.0.4` to `2023020000.1.0`
Introduces 2 new commits in Common/MU_TIANO.
Commits
- fd4fa1 Repo File Sync: Add extra_cargo_steps parameter to MuDevOpsWrapper.yml (#175)
- 93034d CodeQlFilters.yml: Glob file patterns in nested directories (#177)
Signed-off-by: Project Mu Bot mubot@microsoft.com

Bump Common/MU from 2023020001.4.1 to 2023020001.5.0 @ProjectMuBot (#698)
Change Details
Bumps Common/MU from `2023020001.4.1` to `2023020001.5.0`
Introduces 2 new commits in Common/MU.
Commits
- 88d3dd Repo File Sync: Add extra_cargo_steps parameter to MuDevOpsWrapper.yml (#305)
- a3d53e CodeQlFilters.yml: Glob file patterns in nested directories (#307)
Signed-off-by: Project Mu Bot mubot@microsoft.com

Bump MU\_BASECORE from 2023020006.0.0 to 2023020006.1.0 @ProjectMuBot (#696)
Change Details
Bumps MU_BASECORE from `2023020006.0.0` to `2023020006.1.0`
Introduces 1 new commits in MU_BASECORE.
Commits
- 8ea518 CodeQlFilters.yml: Glob file patterns in nested directories (#552)
Signed-off-by: Project Mu Bot mubot@microsoft.com

Full Changelog: v4.4.1...v4.5.0

Contributors

makubacki and ProjectMuBot

Assets 7

Releases: microsoft/mu_tiano_platforms

v4.7.3

What's Changed

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

v4.0.0

What's Changed

New Contributors

v3.1.3

What's Changed

v3.1.2

v3.1.1

v3.1.0

What's Changed

How This Was Tested

Integration Instructions

Contributors

v4.7.2

What's Changed

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

🔐 Security Impacting

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

🛠️ Submodule Updates

Contributors

v4.7.1

What's Changed

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

🐛 Bug Fixes

How This Was Tested

Integration Instructions

🛠️ Submodule Updates

Contributors

v4.7.0

What's Changed

How This Was Tested

Integration Instructions

🚀 Features & ✨ Enhancements

How This Was Tested

Integration Instructions

🛠️ Submodule Updates

Contributors

v4.6.1

What's Changed

How This Was Tested

Integration Instructions

🛠️ Submodule Updates

Contributors

v4.6.0

What's Changed

🚀 Features & ✨ Enhancements

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

📖 Documentation Updates

How This Was Tested

Integration Instructions

🛠️ Submodule Updates

Contributors

v4.5.3

What's Changed

How This Was Tested

Integration Instructions

Description

How This Was Tested

Integration Instructions

🛠️ Submodule Updates

Contributors

v4.5.2