Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Can Legacy versions (e.g. 1.2.3.4) be used for packages in a ProGet Universal feed?
-
We are testing the Jenkins plugin to publish a Universal package to ProGet and it only allows versions in the format : x.x.x
From the documentation I see that NuGet feeds support two different version formats:
https://inedo.com/support/kb/1157/nuget-version-number-formatting-restrictionsFrom the upack command line reference and documentation it looks like Universal packages might also support longer versions. I cannot see any discussion about the version restrictions for universal packages.
This page indicates longer versions are allowed:
https://inedo.com/support/documentation/upack/universal-packages/package-identification
But there is no mention here:
https://inedo.com/support/documentation/upack/tools-and-libraries/upack-cli
Is this a bug (or limitation) in the Jenkins Inedo Proget plugin?
Product: ProGet
Version: 5.1.3
-
Universal packages support SemVer2, which is a three-part version number scheme with additional labels for pre-release and build metadata.
The NuGet "4-part" scheme was proprietary, undocumented, and had very strange quirks and behaviors, which is why NuGet has deprecated it years ago.
If you absolutely need to use a proprietary/non-standardized version number, then I recommend you to just add it as metadata to the package (
_myVersionor_componentVersion) .
-
Thanks for the suggestion - I'd already thought of that. But (not having tried yet) I don't see how it would help.
The reason for wanting to use a four-part version number is this; Like most software companies we use a branch-merge strategy for product support. For each product support fix we create a branch and assign a version using the 4th number (e.g. 1.2.2.1) indicating revisions on the branch (to ensure all shipped components have distinct version numbers traceable back to the source code). When the branch is merged/closed the new trunk version will be assigned a 'normal' (3-part version number 1.2.3)
Correct me if I'm wrong, but if ProGet enforces SemVer2 versions for Universal Packages, then we won't be able to post two different versions of a component to a feed. In this case they would have the same package version, but different metadata. Does ProGet Allow that?
-
A package is uniquely identified by its version, so different package versions will need different numbers. But I think you can use the pre-release labels, at least in some sort of way to do product support?
Take a look at this video from our recent Hedgehog webinar: Using Semantic Versioning to Overcome Package Deployment Challenges. You can see the whole webinar on the Hedgehog page as well.
-
I see what you mean. Though in this video the suffix is used for dev versions or release candidates. But I guess we could (ab)use this for branches.
Will try and see how it goes.
