You've recently release 4.8.1 which contains an important fix for running in offline environments. Unfortunately NuGet.Commandline package is not updated and still at 4.7.1 (while NuGet.CommandLine.XPlat is at 4.8) and there are no release notes available here.
Can you please properly release 4.8.1 on all channels and with full release notes.
pascalberger
All 13 comments
Thanks for the issue @pascalberger. Definitely something we could have done better. I guess the hurry to unblock developers due to #7008 caused us to release 4.8.1 exe before we could prepare a synchronized release. I will look into this and get the other pieces together asap.
anangaur
on 4 Sep 2018
/cc: @rrelyea @karann-msft
anangaur
on 4 Sep 2018
@anangaur Thanks for taking care of this.
As being the reported of #7008 I would have prefered if you would have taken your time and release it properly, in which case I might be able to use it by now, what is not possible currently due to the missing pieces. If you want to unblock people quickly why not release a pre-release version (For this case I already had a testversion)?
What's getting boring is that I reported similar stuff already for 4.3, 4.4.1, 4.7 where you forgot to update the nuget.commandline nuget package, and 4.7.1 were release notes were missing. So there seems to be some kind of pattern here.
Also currently there's still a big mess with versioning, between what you make available on https://dist.nuget.org/index.html, the nuget.commandline and nuget.commandline.xplat package. Also your proces doesn't match with what you've written in #4851 how your process should look like.
For example nuget.commandline has version 4.7.1 has no release notes, NuGet.CommandLine.XPlat has a version 4.8.0 which doesn't even exist elsewhere. There's more mismatch if you compare https://dist.nuget.org/tools.json and the two NuGet packages.
Also I don't see why you make a difference between Released and ReleaseAndBlessed versions if you still fail at stuff like failing self update, which happened with 4.7.0, and which is even explicitely mentioned in #4851 as a use case for the NuGet.CommandLine package. Why not just have a set of proper integration tests for stuff like this and a release pipeline which publishes all the artifacts. IMHO this would lead to much more stable release scenarios than what we have now.
pascalberger
on 4 Sep 2018
@anangaur Do you have any plans when the missing pieces will be released?
pascalberger
on 6 Sep 2018
@anangaur How does it look regarding release notes and requirements for 4.8.1? I tried to update to be able to use signed packages, but I'm running into issues (https://github.com/NuGet/Home/issues/7292). Maybe this is a known restriction or requirement which I'm missing in 4.8.1, but without proper documentation I have no clue, and therefore I'm still unable to upgrade to any nuget packages which are released since you introduced repository signing, including all security updates.
pascalberger
on 11 Sep 2018
As the changes from 4.8.1 are now also deployed with Visual Studio based on this comment, it now definitely should be the recommended version and deserves proper release notes
pascalberger
on 12 Sep 2018
Release notes are here - https://docs.microsoft.com/en-us/nuget/release-notes/nuget-4.8-rtm
karann-msft
on 12 Sep 2018
While now finally recommended, parts on nuget.org are still missing: #7504
pascalberger
on 13 Nov 2018
Still missing Nuget 4.8.1 Command Line package. It's also missing from the XPlat packages.
To give an example of a real world effect of this - Teamcity uses the Nuget Command Line nupkg for its own Nuget runners, if you're looking to do a nuget restore which requires that client then you'll need to create your own nupkg currently.
fenneh
on 5 Dec 2018
@fenneh 4.8.1 had release issues, 4.9.1 is expected to be released in the near future.
devlead
on 5 Dec 2018
any news about syncing those things?
there is 4.9.2 already available and if this package does not keep up it should be obsoleted as now it is just misleading.
quasarea
on 14 Dec 2018
@quasarea 4.9.2 is not blessed/recommendet yet, I expect that they will update the nuget.commandline package once it is blessed. 4.8.1 is still the recommendet version, but due to release issues with this version, nuget.commandline is still on the previous recommendet version which is 4.7.1
pascalberger
on 14 Dec 2018
Closing as 4.9.2 is now blessed
pascalberger
on 22 Dec 2018
Related issues
livarcocc
路
3Comments
livarcocc
路
3Comments
vsfeedback
路
3Comments
rrelyea
路
3Comments
philippe-lavoie
路
3Comments
Most helpful comment
@anangaur Thanks for taking care of this.
As being the reported of #7008 I would have prefered if you would have taken your time and release it properly, in which case I might be able to use it by now, what is not possible currently due to the missing pieces. If you want to unblock people quickly why not release a pre-release version (For this case I already had a testversion)?
What's getting boring is that I reported similar stuff already for 4.3, 4.4.1, 4.7 where you forgot to update the
nuget.commandlinenuget package, and 4.7.1 were release notes were missing. So there seems to be some kind of pattern here.Also currently there's still a big mess with versioning, between what you make available on https://dist.nuget.org/index.html, the
nuget.commandlineandnuget.commandline.xplatpackage. Also your proces doesn't match with what you've written in #4851 how your process should look like.For example
nuget.commandlinehas version 4.7.1 has no release notes,NuGet.CommandLine.XPlathas a version 4.8.0 which doesn't even exist elsewhere. There's more mismatch if you compare https://dist.nuget.org/tools.json and the two NuGet packages.Also I don't see why you make a difference between
ReleasedandReleaseAndBlessedversions if you still fail at stuff like failing self update, which happened with 4.7.0, and which is even explicitely mentioned in #4851 as a use case for theNuGet.CommandLinepackage. Why not just have a set of proper integration tests for stuff like this and a release pipeline which publishes all the artifacts. IMHO this would lead to much more stable release scenarios than what we have now.