Refactor GenerationResult to restore the original behavior of writing JSON arrays for SPDX 2.2 by pragnya17 · Pull Request #975 · microsoft/sbom-tool (original) (raw)
Conversation
The previous SBOM tool (version 3.1) created SPDX 2.2 SBOMs by ending JSON arrays if it was started. A JSON array is started if the sbomConfig supports it. Then, we iterated through all the supporting sbomConfigs to end the JSON array.
However, during the refactoring of code to support SPDX 3.0, this logic was changed and we instead started relying on if the array was empty or not in order to end JSON array. This PR reverts that behavior change by refactoring the GenerationResult class to include if the JSON array was started or not. This condition is then used to end the JSON array.
ppandrate and others added 10 commits
…andrate_spdx3.0ExternalDocRefsBug
…cRef GenerationResult. Add documentation.
This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:
- Changing the signature of an existing interface method
- Adding a new method to an existing interface
- Adding a required data member to a class that an existing interface method consumes
Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:
Option 1 - Publish this as a breaking change
- Update the documentation to show the new functionality
- Bump the major version in the next release
- Be sure to highlight the breaking changes in the release notes
Option 2 - Refactor the changes to be non-breaking
- Review this commit, which adds a new interface in a backward-compatible way
- Refactor the change to follow this pattern so that existing interfaces are left completely intact
- Bump the minor version in the next release
Refactor generation result Refactor GenerationResult to restore the original behavior of writing JSON arrays for SPDX 2.2
This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:
- Changing the signature of an existing interface method
- Adding a new method to an existing interface
- Adding a required data member to a class that an existing interface method consumes
Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:
Option 1 - Publish this as a breaking change
- Update the documentation to show the new functionality
- Bump the major version in the next release
- Be sure to highlight the breaking changes in the release notes
Option 2 - Refactor the changes to be non-breaking
- Review this commit, which adds a new interface in a backward-compatible way
- Refactor the change to follow this pattern so that existing interfaces are left completely intact
- Bump the minor version in the next release
ppandrate and others added 2 commits
This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:
- Changing the signature of an existing interface method
- Adding a new method to an existing interface
- Adding a required data member to a class that an existing interface method consumes
Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:
Option 1 - Publish this as a breaking change
- Update the documentation to show the new functionality
- Bump the major version in the next release
- Be sure to highlight the breaking changes in the release notes
Option 2 - Refactor the changes to be non-breaking
- Review this commit, which adds a new interface in a backward-compatible way
- Refactor the change to follow this pattern so that existing interfaces are left completely intact
- Bump the minor version in the next release
This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:
- Changing the signature of an existing interface method
- Adding a new method to an existing interface
- Adding a required data member to a class that an existing interface method consumes
Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:
Option 1 - Publish this as a breaking change
- Update the documentation to show the new functionality
- Bump the major version in the next release
- Be sure to highlight the breaking changes in the release notes
Option 2 - Refactor the changes to be non-breaking
- Review this commit, which adds a new interface in a backward-compatible way
- Refactor the change to follow this pattern so that existing interfaces are left completely intact
- Bump the minor version in the next release
This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:
- Changing the signature of an existing interface method
- Adding a new method to an existing interface
- Adding a required data member to a class that an existing interface method consumes
Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:
Option 1 - Publish this as a breaking change
- Update the documentation to show the new functionality
- Bump the major version in the next release
- Be sure to highlight the breaking changes in the release notes
Option 2 - Refactor the changes to be non-breaking
- Review this commit, which adds a new interface in a backward-compatible way
- Refactor the change to follow this pattern so that existing interfaces are left completely intact
- Bump the minor version in the next release
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
2 participants
