The latest stable version available for the BingMapsRESTToolkit is 1.1.4 from nuget.com, while the actual latest release is 1.1.5. I'm wondering if this is ever going to be updated? The nuget was last updated in March of 2018.
There's currently someone forking the Microsoft repo and keeping the nuget updated as a stopgap.
Related
How can I create a shields.io badge that will display the latest pre-release, excluding later releases?
The behavior allows for inclusion of a later pre-release, but I want to separately list the latest released version and the latest pre-release version, even when the latest released version is greater than the last pre-release.
E.g.
From the GitHub Releases the last pre-release version was 2.7.10-ga8a94550e6.
The behavior works until I merge from develop to main, and then the release version supersedes the pre-release version, and the badge no longer works as expected.
How do I get the latest GitHub pre-release excluding non-prerelease builds?
I am new to Azure Devops. I want to use Azure artifact to publish my build artifacts there so that we can use them as a Maven dependency. The issue I am facing is when I deploy a newer version of my artifact, it overrides the previous version. This can lead to issues for the user of my artifacts.
Is there any specific settings using which I can change this behaviour?
According to your description you are using the Azure Artifact feed, right?
If it is, then the old version of packages will not be overwritten by the new versions. By default we can see the latest version of packages in the feed home page. However we can click the specific package, then switch to the Versions tab to check the old versions of that package.
Then you can reference the specific version of the packages in your project.
I created a private NuGet feed in Azure DevOps following this guide and created a build pipeline with dotnet pack and dotnet nuget push steps. After running the build a few times, the new versions are displayed under Artifacts >> MyFeed >> Versions. I promoted some of the versions by hand to #Release.
Here's the view in DevOps:
But when I connect to the feed in Visual Studio, I only see version 1.0.0 as stable release, but all later versions (which are published via my build pipeline), are only shown if I check the "include pre-release" option. Here's a screenshot:
My questions are:
1 - how can I manually promote a version to stable?
2 - how can I promote a version to stable via a build or release pipeline?
Azure DevOps - Private NuGet feed doesn't update stable release
Just like zivkan said "anything after a - character signals pre-release information.". You can check the nuget document Package versioning for some details.
1 - how can I manually promote a version to stable?
You can download that package from your nuget feed, then change the package version to stable, then re-push it to the feed.
2 - how can I promote a version to stable via a build or release pipeline?
To promote a version to stable via a build or release, you could change the build number. When you use dotnet pack task to create the nuget package, there is an option Automatic package versioning:
Update:
So, try to use the option Use the build number option on the Automatic package versioning.
Then, in the Build number format option, you can set it to $(Major).$(Minor).$(Patch)$(Rev:.r):
The value of $(Major), $(Minor), $(Patch) are custom variables in the Variables tab, the value of $(Rev:.r) is the build number.
In this case, the package will be TestSample.1.0.0.5.nupkg.
Hope this helps.
NuGet uses Semantic Versioning 2.0, which says that anything after a - character signals pre-release information. Therefore 1.0.1-CI is prerelease, whereas 1.0.1 would be a release version. If you want build metadata in the version string, you should use the + character, again as defined by SemVer2.
edit: note that SemVer metadata does not contribute to version comparisons, so 1.2.3+CI.1 is considered the SAME version as 1.2.3+CI.2
When we push a new version of a NuGet package to our NuGet feed the package will appear in the file system on the NuGet server. The NuGet feed API and in visual studio, however only update roughly every hour so we may have to wait up to an hour for new packages to show. Is there a way to force update the NuGet feed to accurately depict what is in the file system?
I've encountered very similar issue, after publishing new package version to private TeamCity NuGet feed it hasn't appeared in visual studio immediately. It took time to update.
However, new package version itself was available via request:
http://<teamcityserver>/guestAuth/app/nuget/v1/FeedService.svc/Packages(Id='<packageId>',Version='<newPackageVersion>')
For example:
http://test:8111/guestAuth/app/nuget/v1/FeedService.svc/Packages(Id='TestPackage',Version='1.0.1')
I resolved it by cleaning local NuGet cache
via
Tools → Options → NuGet Package Manager → General → Clear all NuGet cache(s)
or
dotnet nuget locals all --clear
See related answer:
https://stackoverflow.com/a/42665980/2793919
I am currently designing an automated build environment for releasing of various NuGet packages for my organisation.
As it stands, I want to be able to produce various "levels" of stability for NuGet releases, starting with triggered (i.e: builds made by POST hooks on the develop branch) as a replacement for nightlies, followed by source promoted to alpha/beta, RC then "stable" packages.
NuGet has stable and prerelease options for package retrieval, however, prerelease cannot distinguish between different prerelease stages, such as 1.2.3-beta123 and 1.2.3-alpha123 etc.
Is there any way to allow package consumers to select the "lowest" level of stability they would like to subscribe to? AFAIK, the only solution is to create different feeds that are selectively published to during the build process, then work from there. Refer to something like the Xamarin Studio Update setting below;
This is not something that is built in to NuGet. NuGet separates NuGet packages by their source.
Some teams publish nightly builds to MyGet and only publish official release NuGet package builds to nuget.org but that is just a split of pre-release from release which you could do on one package source.