Feature request: patch roll forward

[tmds]

This feature request is inspired by dotnet/designs#36 which proposes automatic patch roll forward the .NET Core runtime used in self-contained apps.

Generalizing this for any NuGet package: allow marking a package to have 'patch roll forward' semantics. The maintainer can then provide patch releases, which are automatically consumed by new builds.

At some point, the maintainer will stop patching the version, so deprecating packages (#2867) is needed too.

CC @dsplaisted @natemcmaster

[davidfowl]

No I think think this should be a thing. It causes so many problems and would require the introduction of a lock file.
This is a consumption time feature not an authoring time feature.

Being able to marking a package deprecated makes sense so the client can earn but automatically rolling forward on patches causes other problems.

PS: Nuget used to do this automatically and we removed that behavior because your package install graph changes depending on what day you installed it. This isn’t the case today unless somebody deletes packages from a feed

[tmds]

ok, perhaps a bad start by proposing a solution.

use-case: as a developer I want my application to include important fixes (especially: security fixes)

[nkolev92]

From the discussion here, I'm assuming you're asking for an npm tilde equivalent in the nuspec?

NuGet's implementation of ^ and ~ is *, but it's only used in package declaration, not in the nuspec.
#5553 (comment)

There's an ask for changing the pessimistic resolution strategy to Highest in the same issue.

I'd like to dupe this out to #6770, add the comments there and continue the discussion.

I'm with @davidfowl though, floating/bumping up versions is and should stay a consumption time feature.
/cc @jainaashish @rrelyea

[jainaashish]

use-case: as a developer I want my application to include important fixes (especially: security fixes)

You should include that package as direct dependencies and control it's behavior to upgrade to include those important fixes. After having multiple discussions recently, I too think that it will be a bad design to allow consumers to control resolution strategy for transitive world, which will eventually end up creating more problems than solving few edge cases.

[tmds]

From the discussion here, I'm assuming you're asking for an npm tilde equivalent in the nuspec?

I don't know what this tilde is, but if it is a wildcard version dependency, then: no, that is not what I'm asking.

I want the maintainer of the package to be able to push me a more recent version when he thinks that is appropriate.
This is similar to how my OS gets continuous updates because the package maintainers are push fixes.

The maintainer must be committed to provide such patch releases. So this doesn't apply to every package.

The packages provided by Microsoft that make up .NET Core follow this model. Mechanisms are in place to provide users with the latest patched versions and make applications use that version (roll forward).
This isn't based on NuGet. As a NuGet library maintainer, you can't do this.

You should include that package as direct dependencies

I may not even know I am using a package that has a security issue.

[dsplaisted]

use-case: as a developer I want my application to include important fixes (especially: security fixes)

You should include that package as direct dependencies and control it's behavior to upgrade to include those important fixes. After having multiple discussions recently, I too think that it will be a bad design to allow consumers to control resolution strategy for transitive world, which will eventually end up creating more problems than solving few edge cases.

We should consider how a developer would discover that such updates are available (currently I'm not aware of any tooling to help with this). We should also consider the impact of having to promote transitive dependencies to direct ones just for this purpose- as you no longer capture the intent of what you intend to directly reference, and may run into issues such as package downgrades as your dependencies get updated over time.

[nkolev92]

Commands like outdated could be implemented to help discover NuGet packages that are not current. #5762

Note that not current doesn't mean bad, or unsafe.
As mentioned in #5553 already, not every patch update is security update. There is no way for NuGet to know if an update is a security update or not.
There's already some misconceptions about the updates tab and how often users think it's a NuGet recommended version.

The npm ~ (tilde) is exactly what NuGet's * is. The difference is that, ~ can be both a consumer and author decision, while the * is a consumer time decision only.

I think the OS parallel is not a great one. It's the equivalent of having all the packages with *s. Also all the packages are explicitly defined. No implicit transitive dependencies.

[tmds]

We should consider how a developer would discover that such updates are available (currently I'm not aware of any tooling to help with this)

Yes. For example, if I am using 'Microsoft.AspNetCore.All' version '2.0.6', there is no way for me to figure out '2.0.7' is available. I may not be depending on that package directly.

Note that not current doesn't mean bad, or unsafe.
As mentioned in #5553 already, not every patch update is security update. There is no way for NuGet to know if an update is a security update or not.

The maintainer knows this, but there is no way to convey this in his NuGet package.

The npm ~ (tilde) is exactly what NuGet's * is. The difference is that, ~ can be both a consumer and author decision, while the * is a consumer time decision only.

I need to look into this a bit more.

I think the OS parallel is not a great one. It's the equivalent of having all the packages with *s. Also all the packages are explicitly defined. No implicit transitive dependencies.

Yes, for the OS it is the equivalent of having all the packages with '*' since they get updated automatically. I'm not sure what you mean by there being no implicit transitive dependencies.

An OS will have very strict guidelines for what packages updates are allowed. For example: https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases.

If you can't live up to these rules your packages won't be part of the OS feeds.

Similarly, patch forward doesn't apply to every NuGet package. This is why I'm suggesting the maintainer should be capable of expressing he is committed to update his packages in an appropriate way.

[tmds]

When referencing dotnet/designs#36 I thought everything was fixed with a custom solution. However that design is also missing the ability to figure out the latest patch version:

As proposed, the .NET Core SDK targets will have a hard-coded list of the latest patches for each minor .NET Core release. This couples SDK releases with runtime patches and means we would have to release an updated SDK each time there was a new runtime patch if we want self-contained apps to roll forward to it-- and that developers would need to install the new SDK in order to roll forward to the latest patch.

New templates for ASP.NET Core 2.1 don't include a version number for the package, and have a similar limited awareness of the patch version.

<PackageReference Include="Microsoft.AspNetCore.App" />