You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Should we allow the BOM to pick up new fix versions of specs
(keeping the first two version columns fixed to retain a stable API)?
The requirement for this came from a discussion on what we do when
we get a security vulnerability alert in some dependancy. If the spec
updated to a X.Y.Z++ release (incrementing Z only),
the bom would still reference the old vulnerable artifact in maven central.
See the Oct 8th Architecture call minutes and #132
The text was updated successfully, but these errors were encountered:
hutchig
changed the title
Allow for fix version updates in included specs: e.g. 2.1.* instead of 2.1
Allow for fix version updates in included MP specs: e.g. 2.1.* instead of 2.1
Oct 15, 2019
At the moment to quote Kevin, 'this pom file is really only used when releasing a new version of the MicroProfile platform. If a component has a security patch (or whatever), then they should just submit a PR against the pom.xml to get the upper bounds updated for their component.' We can return to this if desired if the/a top level pom ever gets used as a parent for dependencyManagement.
Should we allow the BOM to pick up new fix versions of specs
(keeping the first two version columns fixed to retain a stable API)?
The requirement for this came from a discussion on what we do when
we get a security vulnerability alert in some dependancy. If the spec
updated to a X.Y.Z++ release (incrementing Z only),
the bom would still reference the old vulnerable artifact in maven central.
See the Oct 8th Architecture call minutes and
#132
The text was updated successfully, but these errors were encountered: