rombert commented on PR #149: URL: https://github.com/apache/sling-site/pull/149#issuecomment-1850465423
> Obviously we don't agree here, so I would appreciate to hear other opinions @cziegeler and @rombert... Tough question, I don't have a good answer for it, but I'm still thinking about it. Trying to restate the problem as I see it: we have two "personas" that we would like to make life easy for: - developers working against less recent Sling-based platforms that would like to deploy new Sling bundles with minimal changes - developers whose projects are enrolled in security scans and that need spend time handling false positives stemming from security scans When I started contributing to the Sling project, we only had the first group. I think questioning the policy that we is good, because as the world changes we should not stay inflexible. I am not sure what the best answer is. I think some good points have been mentioned: - we can't upgrade all dependencies all the time, we simply don't have the time for that - not all dependencies are equal. updates are needed only when a security dependency is reported There are some questions still open for me: ## How many dependency updates are security-sensitive? if we were to embark on a policy of "update for security fixes only", would that make the updates level reasonable? ## How many dependency updates actually affect a released product? It might be that when updating a dependency version this version is already updated in all "relevant" third party products using this bundle. I am thinking about Sling CMS, Starter, AEM, Peregrine, Websight, etc. We don't have that data today (and we never did) so we play on the safe side and say 'lowest possible'. Would it be possible to gather data (or ask for data contributions) so that we know that the minimum baseline is? -- 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]
