Skip to content
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

Closed
dominikjeske opened this issue Mar 11, 2021 · 4 comments · Fixed by #351
Closed

Floating version problem #64

dominikjeske opened this issue Mar 11, 2021 · 4 comments · Fixed by #351
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@dominikjeske
Copy link

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?

@dominikjeske dominikjeske added the bug Something isn't working label Mar 11, 2021
@michalrosenbaum
Copy link

michalrosenbaum commented Mar 11, 2021

Just to visualize/help with reproducing, let's say that we have these packages in the feed:
SomeDependencyOfNestedPack.1.0.1.nupkg
SomeDependencyOfNestedPack.1.0.2.nupkg

If a nested project packed with the root package has the following reference with a floating version such as:
<PackageReference Include="SomeDependencyOfNestedPack" Version="1.0.*" />

The resulting version in the nuspec of the root package is going to be:
<dependency id="SomeDependencyOfNestedPack" version="1.0.0" />

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:

<PackageReference Include="NuGetizer" Version="0.6.0">
    <PrivateAssets>all</PrivateAssets>
    <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>

@kzu
Copy link
Member

kzu commented Mar 13, 2021

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 kzu added wontfix This will not be worked on question Further information is requested and removed bug Something isn't working labels Mar 13, 2021
@kzu kzu closed this as completed Mar 13, 2021
@maciejw
Copy link

maciejw commented Mar 14, 2021

@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:
I've checked it on sample project
here is package reference

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

@kzu kzu added enhancement New feature or request help wanted Extra attention is needed and removed question Further information is requested wontfix This will not be worked on labels Mar 14, 2021
@kzu kzu reopened this Mar 14, 2021
@kzu
Copy link
Member

kzu commented Mar 14, 2021

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 👍

kzu added a commit that referenced this issue Mar 19, 2023

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
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
kzu added a commit that referenced this issue Mar 19, 2023
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
@kzu kzu closed this as completed in #351 Mar 19, 2023
kzu added a commit that referenced this issue Mar 19, 2023
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
@devlooped devlooped locked and limited conversation to collaborators Nov 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants