How will we manage dependency updates ?

[fgheysels]

This is somehow related to #271

I agree that we should not blindly update our dependent packages, but we must also make sure that we do update packages when necessary.

When we update packages, users of Azure are only impacted when they use a newer version of our Azure packages, so TBH, I do not see a problem in having renovate updating the packages that we use in Arcus libraries.
We can update packages multiple times a week, but it is only after we create a release, that Arcus users are impacted.

[stijnmoreels]

Maybe we could work with version ranges here, to allow as much support as possible. I think we already do that for some Microsoft packages. So that we take in all minors, for example.

[fgheysels]

I see that you do not want to enforce people to upgrade dependencies because of Arcus.
However, if they are already upgrading Arcus, then we shouldn't they also upgrade other packages that they're using ?

We can try your suggestion regarding updating packages similar with our versioning, but I don't think that this will work in all cases. I mean, Arcus versioning is indepedent from f.i. Azure package versioning.

[stijnmoreels]

I see that you do not want to enforce people to upgrade dependencies because of Arcus.
However, if they are already upgrading Arcus, then we shouldn't they also upgrade other packages that they're using ?

I don't think consumers are always in charge of dependencies. Maybe such a dependency update causes a conflict further up. I don't think it's good service when people ask for a fix release, we release it, and when they install it they have package conflicts and/or problems with availability. Plus, maybe in some cases, the costumer decides when an update should happen (happened to me).
But maybe we can com up with a compromise. What if we use Renovate for all minor/major updates when we release minor's, and we hold-off with dependency updates when we release fix-releases.
This way we have best of both worlds, I guess. We can keep the Renovate PR's open till we actually plan for the minor release. Plus, yeah, maybe we can use package ranges to be able to be as compatible as one can be. What that be alright?

[fgheysels]

My idea would be to automatically update patch & minor versions of dependencies.

When there is a major update of a dependency, we should be notified, so that we can manually decide whether or not we upgrade (and when).

Anyway, we must avoid situations where we are dependent on deprecated packages/libraries.

[stijnmoreels]

Discussed offline, we choose a mutli-target framework approach where we use the lowest .NET 6-supported package. See #188 .

[stijnmoreels]

What we could do to manage deprecated versions, is that we make a habit of it to verify our packages when we release minor/major. If any package is deprecated, we could move towards a new version. This can be an issue as part of a milestone so we don't forget it.