You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Robert Munteanu <rm...@adobe.com.INVALID> on 2022/04/06 13:47:35 UTC

Fwd: [NOTICE] Dependabot Updates enabled for all projects

Hi,

We will start getting dependabot PRs for our sling modules, for
instance

  https://github.com/apache/sling-org-apache-sling-xss/pull/18

While I understand the reasoning behind this service, in Sling we have
long had a policy of depending on the lowest possible version of the
API, to ensure that our bundles are deployed in the widest possible
range of environments.

The situation is different for embedded bundles, but that is an edge
case compared to our regular usage of dependencies.

I suggest that we hold off merging these PRs for now, and if anyone
thinks otherwise we should discuss and potentially amend our practices.

Thanks,
Robert

Re: Fwd: [NOTICE] Dependabot Updates enabled for all projects

Posted by Robert Munteanu <ro...@apache.org>.
On Wed, 2022-04-06 at 11:35 -0700, Eric Norman wrote:
> Perhaps some analysis of whether bumping the dependency version
> changes the
> generated Import-Package instruction can provide some insight
> regarding the
> compatibility.  If the new version of the dependency only has changes
> in
> packages that we are not directly using then it should be safeish to
> switch.

That is an interesting idea. I have looked if something like this is
present in bnd, but apparently it's not.

It is somehow related to baselining and I could see this being printed
as an INFO message during regular baselining runs.

If anyone is interested in pursuing this a good first step would be to
open an issue at https://github.com/bndtools/bnd .

Thanks,
Robert

> I would also support changing our process to depend on the lowest
> possible
> version that doesn't have known vulnerabilities.  Perhaps with some
> announcement if there are known compatibility issues.
> 
> Regards,
> -Eric

Re: Fwd: [NOTICE] Dependabot Updates enabled for all projects

Posted by Eric Norman <en...@apache.org>.
Perhaps some analysis of whether bumping the dependency version changes the
generated Import-Package instruction can provide some insight regarding the
compatibility.  If the new version of the dependency only has changes in
packages that we are not directly using then it should be safeish to switch.

I would also support changing our process to depend on the lowest possible
version that doesn't have known vulnerabilities.  Perhaps with some
announcement if there are known compatibility issues.

Regards,
-Eric

On Wed, Apr 6, 2022 at 7:01 AM Robert Munteanu <ro...@apache.org> wrote:

> (sent the initial email from the wrong account, please reply to _this_
> email)
>
> On Wed, 2022-04-06 at 13:47 +0000, Robert Munteanu wrote:
> > Hi,
> >
> > We will start getting dependabot PRs for our sling modules, for
> > instance
> >
> >   https://github.com/apache/sling-org-apache-sling-xss/pull/18
> >
> > While I understand the reasoning behind this service, in Sling we
> > have
> > long had a policy of depending on the lowest possible version of the
> > API, to ensure that our bundles are deployed in the widest possible
> > range of environments.
> >
> > The situation is different for embedded bundles, but that is an edge
> > case compared to our regular usage of dependencies.
> >
> > I suggest that we hold off merging these PRs for now, and if anyone
> > thinks otherwise we should discuss and potentially amend our
> > practices.
> >
> > Thanks,
> > Robert
>
>

Re: Fwd: [NOTICE] Dependabot Updates enabled for all projects

Posted by Robert Munteanu <ro...@apache.org>.
(sent the initial email from the wrong account, please reply to _this_
email)

On Wed, 2022-04-06 at 13:47 +0000, Robert Munteanu wrote:
> Hi,
> 
> We will start getting dependabot PRs for our sling modules, for
> instance
> 
>   https://github.com/apache/sling-org-apache-sling-xss/pull/18
> 
> While I understand the reasoning behind this service, in Sling we
> have
> long had a policy of depending on the lowest possible version of the
> API, to ensure that our bundles are deployed in the widest possible
> range of environments.
> 
> The situation is different for embedded bundles, but that is an edge
> case compared to our regular usage of dependencies.
> 
> I suggest that we hold off merging these PRs for now, and if anyone
> thinks otherwise we should discuss and potentially amend our
> practices.
> 
> Thanks,
> Robert