[FEATURE REQ] Could you please ship packages more often?

[ericstj]

Library name

Azure.Core, azure.extensions.aspnetcore.configuration.secrets

Please describe the feature.

I noticed that Azure.Core has shipped a new version with updates to its dependencies. For example version 1.44.1 depends on System.Text.Json 6.0.10 where as 1.42.0 still depends on System.Text.Json 4.7.2.

The latest version of azure.extensions.aspnetcore.configuration.secrets that ships from this repo still depends on 1.42.0 - no newer version is available, despite it's dependency from this same repo shipping an update. This will make it harder for folks to get updates to packages that they need. For better or worse.

We try our best to make direct updates available to packages, as it will increase the update velocity. If possible we'd like azure-sdk-for-net to do the same. You don't need to ship only to update the package, but if you're already building and shipping out of this repo, please include packages which will have changes to their dependencies.

[jsquire]

Hi @ericstj. The Azure SDK packages generally ship on a monthly cadence for areas where there is active development taking place, with a notable exception being a large feature requires more time. We don't ship packages that have no development work just to adhere to that cadence; our goal is to reduce noise so that it is clear to customers that when a new version drops, there's benefit in upgrading. As a general rule, we don't ship packages with no local changes just to bump dependencies unless there's a clear need to do so - such as a needed upstream fix for a bug impacting the package or patching of a vulnerability.

In this case, there's no active work taking place for the extensions packages, nor is any planned for the near future. As the current dependency set has no known impactful bugs nor vulnerabilities, I'm not sure the value of shipping a dependency-only release for the extensions packages. That said, if there's a scenario that you're thinking of which we should consider, we'd be happy to discuss.

[github-actions]

Hi @ericstj. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[ericstj]

I'm not asking for a major change to your incremental servicing process. I can see why that's valuable given you ship a lot of packages which are unrelated and may not appear to customers as a single product.

The thing I'd like you to consider changing is this:
When you update dependencies (significantly) in a package, update all packages that depend on it.
I define significant dependency updates as 1) changing the major version of a dependency 2) updating from an out-of-support version of a dependency to an in-support version 3) updating from a vulnerable version of a dependency to non-vulnerable version.

The reasoning here is that your packages are acting as a deployment vehicle for these dependencies, so they really ought to be putting people in the best spot possible. By not shipping a new version (especially when you are already building them and testing them) you're leaving your customers to need to do this as their very first step when they install your packages. It's also leaving "gaps" in the update chain. When folks rely on only updating direct dependencies -- they'll miss that they need to update to get a fix.

I suspect that this won't introduce a substantial increase in the number of things you ship on a regular basis, but it probably will when you make major updates to Azure.Core or react to things like Component Governance warnings.

Here's a sample that shows how you can implement something like this -- https://github.com/dotnet/runtime/blob/50773e83cb8a2f8f9f35cf533dca61f43d670685/eng/packaging.targets#L328-L362. You could further iterate on a solution like this by controlling it with an opt-in property to indicate a significant change was made that should result in upstack packages being enabled.