- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Floating version problem #64
Comments
Just to visualize/help with reproducing, let's say that we have these packages in the feed: If a nested project packed with the root package has the following reference with a floating version such as: The resulting version in the nuspec of the root package is going to be: The floating part always evaluates to "0". It creates a problem since such a version doesn't even exist in the feed, so later during restore the version 1.0.1 will be taken because it's the nearest to 1.0.0, but it's not the latest. This is how we reference NuGetizer:
|
You can't reference floating versions when packing. This is not supported in nuspec neither nuget packaging APIs, AFAIK. And it makes sense, since you would end up with non-deterministic packages where the exact same checkout/commit can produce different packages. |
@kzu this is interesting problem, but correct me if I'm wrong, restore can use floating version and pack is using version that was restored at the time, that is in package.assets.json? with lockfile (its an assets json that is commied to repo) you have deterministic restore and in nuspec you should have fixed version. even with fixed version in packagereferece you have kind of floating behavior, because version in package reference means version equal or greater and when packages is feed change, restore graph can change also, even if you are using same exact commit. Update: <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Lib1" Version="1.0.*" />
</ItemGroup>
</Project> here is nuspec after dotnet pack <?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
<metadata>
<id>Lib2</id>
<version>1.0.0</version>
<authors>Lib2</authors>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Package Description</description>
<dependencies>
<group targetFramework=".NETStandard2.0">
<dependency id="Lib1" version="1.0.2" exclude="Build,Analyzers" />
</group>
</dependencies>
</metadata>
</package> |
Fair point. This is very low priority for me personally since I never use checked-in lock files, so I get my determinism from the actual fixed versions in the package reference instead (and let dependabot bump those for me as needed). I'll gladly take a PR that adds this behavior, though. Perhaps the right sponsorship level would also work :). Thanks for clarifying the intended scenario and expected behavior 👍 |
When dependency has a wildcard, we can use the exact same approach we use to resolve empty version in centrally managed package versions. Fixes #64
When dependency has a wildcard, we can use the exact same approach we use to resolve empty version in centrally managed package versions. Fixes #64
When dependency has a wildcard, we can use the exact same approach we use to resolve empty version in centrally managed package versions. Fixes #64
I'm using nugetizer 0.6 and have following issue when using floating versions. In my project I have PackageReference like this
<PackageReference Include="packageName" Version="1.0.1-preview.*" />
on my artifactory I have this package in versions from preview.1 to preview.6 but package created from my project have dependency with version 1.0.1-preview.0
When nugetizer is removed from project package dependency have proper 1.0.1-preview.6 version which point to actual version. It looks like nugetizer is not handling floating versions properly?
The text was updated successfully, but these errors were encountered: