mirror of
https://github.com/semver/semver.git
synced 2026-07-10 19:50:47 -05:00
[GH-ISSUE #506] Suggestions for expressing Semantic Versioning when dealing with audited projects/solutions? #4618
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#4618
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @dealproc on GitHub (Mar 29, 2019).
Original GitHub issue: https://github.com/semver/semver/issues/506
I am in the process of developing an application that must meet certain security standards. Within the requirements of the standards, anything "stated" as the version of the product, when security changes or patches to the system that affect security of the code, the stated version MUST change to reflect this. Applications of this nature that MUST go through this sort of scrutiny would benefit from some explanation of how to proceed with how to respect SemVer or a similar flow to express that, maybe, a minor version within these applications could indicate what is now a major version release.
Would love to hear feedback on this thought process and/or if anyone has suggestions on how to structure wrokflow/release versioning when needing this workflow.
@jwdonahue commented on GitHub (Mar 31, 2019):
What exactly are you asking for here?
When dealing with audited projects/solutions, follow the SemVer rules. When you follow the SemVer rules, you will meet the requirement that any security related changes should result in a version change, because ALL changes require a version bump on one of the triples.
@jwdonahue commented on GitHub (Aug 16, 2019):
@dealproc, unless you have further questions, please close this thread at your earliest possible convenience.