enapps-enorman commented on PR #149: URL: https://github.com/apache/sling-site/pull/149#issuecomment-1874774474
@kwin > Can you propose changes for sections you don't agree with or are you fine with the remarks from @cziegeler? The following is the only statement that I would like to see more clarity on since the "lowest version" doesn't consider known security vulnerabilities when choosing the version to depend on. > The version of the module dependency should be selected according to the following rule: **The lowest version providing the functionality required by the module (or bundle)**. By required functionality we basically mean provided API. For me, the rules for dependency version should prefer the oldest version that doesn't contain any known security vulnerability with guidelines like this: 1. When the generated "Import-Package" clause does not materially change then it should be preferred to bump the dependency to this version. This would make the security scanning tools not flag this as problem and should not alter the binary compatibility at all. 2. When the generated "Import-Package" clause does materially change, then bump the "minor segment" of the bundle version number and continue further development with this as the new base version number. Changing the "minor segment" of the bundle version leaves that previous minor bundle version namespace available for any fixes that need to be backported and released on the older branch. This should make it possible to support consumers who can't upgrade to the new version. This backport scenario would probably be rare so I would treat it as an "on demand" situation. I would imagine that some of this decision could be assisted with a bnd plugin that could do some calculations against the baseline version of the bundle. Maybe some codified tooling that enforces the above and the other bundle version rules from https://sling.apache.org/documentation/development/version-policy.html#evolution-of-bundle-versions -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
