[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.

[jsquire]

The good news is that we do perform releases for scenarios 2 and 3 in your list, following guidance from the .NET security team (generally Barry and/or Levi) for when to keep to our normal monthly cadence or react as a hotfix.

That leaves us scenario 1 for consideration. This is an area where we're in the midst of making adjustments. Historically, we've had differing opinions within the team, but the prevailing perspective was that we should keep dependencies locked to the lowest supported version with the feature set that we rely on. The rationale was that we should be avoid implicitly hoisting versions for other transitive dependencies and potentially causing downgrade warnings for the application itself.

More recently, we've revisted and agreed that we'll align our dependencies with major associated with the latest LTS version. We started this for .NET 6 but the process has been slow due to a large number of dependencies that we had not upgraded for an extended period. We're in the process of bumping everything to the 8.x line but have some incompatibilities to work through and also must coordinate upgrades with hosts like Azure Functions and PowerShell, so it's taking us a bit to get fully transitioned.

I think you raise some good points and agree that it's reasonable to release inactive packages at those transition points when we bump to a new major line. There are some conversations that I need to have but I don't believe there will be strong dissenting opinions, but I believe we should be able to include these as part of the 8.x bump work. I'm going to mark this as addressed, but I'm happy to talk further. Please feel free to reach out directly.

[github-actions]

Hi @ericstj. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text "/unresolve" to remove the "issue-addressed" label and continue the conversation.

[jsquire]

Tracking items:

• #48007
• #48008