In deprecation UI, alternate package with "*" range shows >= 0.0.0

[joelverhagen]

Details about Problem

NuGet product used: Package Manager Console
NuGet version: 5.5.0.6293
VS version: 16.5.0 Preview 1.0 [29430.205.master]
OS version: Windows 10 Version 1909
Worked before? Yes with 5.4.0.6271

Likely changed behavior with NuGet/NuGet.Client#3079.

Detailed repro steps so we can see the same problem

1. Open PM UI
2. Go to Browse tab
3. Make sure only nuget.org is the selected source
4. Search for Test4Nuggets
5. Select that package and look at the right side pane where it has deprecation information

It shows >= 0.0.0. I think this is confusing because 0.0.0 is not a real version on most packages and is kind of a side-effect of * having a minimum version of 0.0.0 in memory.

Other suggested things

Screenshot

Compare to nuget.org:

/cc @xavierdecoster @nkolev92 @scottbommarito @anangaur @xavierdecoster

[anangaur]

The intention was never to show a version if it’s not specified (*). Definitely a bug (not a feature) ;-)

[nkolev92]

Is this something you want fixed in 5.5 @anangaur?

If so, we should schedule this.
//cc @rrelyea @skofman1

[donnie-msft]

@anangaur what is the suggestion then, to use afine * here ?
Are we sure this is more clear? Even with (*), it looks more like a footnote to me and may be confusing.

Should we spell out afine (any Version) or afine (* version) or similar?...

[anangaur]

My be just the package ID?

[donnie-msft]

Maybe just the package ID?

As a developer, I'm fine with seeing the original 0.0.0.0, as I find that intuitive. However, short of that, my expectation would be to always see something for version, eg package.name (all), package.name (any), etc.

I think we should set the precedent that version# is a critical part of the ID for a package.
So the question becomes, is a package "name" an incomplete ID, or is the "name" implying all versions?
In conversations, this can be implied by context, but in the PM UI, I think we should have explicit expectations, at least in individual text areas. (details pane should always show a full ID, not sometimes an implied ID).

We are changing other strings to say "package version is vulnerable", not just "package X is vulnerable".
Going from package.name (>= 1.0.0.0) to package.name feels a little contradictory to that.

[anangaur]

My comment on showing just the package ID was for cases where it's 'any version' or '*'. For other cases where a version is specified, we should definitely show the version.

[donnie-msft]

My comment on showing just the package ID was for cases where it's 'any version' or '*'.

Yes, understood. Just that I think we have to state any, rather than <blank>, or it's inconsistent.

[anangaur]

I would be fine with 'any version' or similar text as well :). 0.0.0 feels odd. FYI - @chgill-MSFT

[chrisraygill]

I should point out that there is no option for "*" or "any version" when deprecating a package. You can only suggest specific versions of an alternative package or suggest using the latest version. The PMUI currently shows (>=0.0.0) when "Latest" is selected as the suggested version which is the opposite of the intent 😅

From https://www.nuget.org/packages/Contoso.nuget.example/1.2.3:

NuGet.org doesn't show the version of the alternate package when "Latest" is selected by the owner because latest stable is typically the assumed best choice when no version is specified (it's what we show by default in the PMUI Browse and Updates tabs). When you click on the linked package name - it automatically open the alternate package details page to the latest stable version.

When the package author has chosen "Latest" I think we have 3 choices to consider:

1. Don't show any version - link to either the latest stable or latest including prerelease depending on if "Include prerelease" is enabled.
2. Show "(latest version)" - link to either the latest stable or latest including prerelease depending on if "Include prerelease" is enabled.
3. Show "(latest stable)" - always link to the latest stable regardless of the state of "include prerelease".

Our decision here may also mean we should open an issue to be more specific on NuGet.org as well 😉

What do y'all think? - @anangaur

[chrisraygill]

Copying my response from the closed issue:

@dominoFire IMO we should just open the package details window to the default version given their search preferences.

If they have Include prerelease enabled, then show the latest stable/prerelease version. If they have Include prerelease disabled, then show the latest stable version.

This is already how browse works in the PMUI today in normal search scenarios. NuGet.org works a little differently, but I think somewhat incidentally. On NuGet.org the alternate package deprecation link goes to nuget.org/packages// with no version specified which goes to the latest stable version. On NuGet.org, there's nowhere to specify a preference for prerelease or stable versions on the package details page - only in search.

TL;DR

Let's do what's most natural to the PMUI already which isn't exactly what NuGet.org does.

In the case of afine >= 0.0.0 today, instead:

Don't show any version - open the linked package to the latest stable or latest including prerelease depending on if "Include prerelease" is enabled.

[chrisraygill]

@dominoFire any update on this? Seems like a nice polish :)