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?
Related
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.
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
I'm making an npm package and I published it as version 1.0.0 because I was happy with the public API. But now, I'm in the process of adding an "examples" subproject to showcase how to use the library. Obviously, I won't publish the example project as a part of the library (it will be added in .npmignore), but it will be on my github repo. Is there any semantic versioning rules for that? Should I update the patch version, minor version or nothing at all?
On one hand, I think I shouldn't update the version since it won't be published to npm, therefore normal users of the app won't even notice a difference in the package. On the other hand, semver rules say you should update the "patch" or "minor" version when you make documentation changes, even though the documentation isn't published either.
The relevant spec here is #3:
Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version.
Since nothing was added to your API and it's obviously not a breaking change, you should bump the patch number.
For Crashlytics, I'm trying to upload release notes using:
notes: changelog_from_git_commits
How do I limit the changelog to contain only the changes from the last release/upload?
I know that there is something between: option but that allows only using a revision or tag which is quite hard to automate. How to automate the limit to the last release?
By default changelog_from_git_commits assumes your release policy involves using git tag to tag the code revision used to build each release. So changelog_from_git_commits reports the commits since the most recent tag by default.
So don't tag until you've run changelog_from_git_commits