How to handle non-semver versions with packages

jstarbird_7831

We have a couple of products that are 10+ year established code base and a very large code base on top of that. So changing the versioning of these products is not going to happen anytime soon.
Just prior to 5.x you had introduced the Deployment feeds which allowed, still widely used, 4 placed versioning like 1.0.0.4. This allows me to store multiple versions of packages in the feed.
I still have two of these Deployment feeds but I cannot create anymore, so my question is how can I handle the need to keep multiple build packages around in a ProGet feed, say a Universal one? So if I upload today 1.0.0.4 and tomorrow need to upload 1.0.0.5 and keep both around for a few weeks how can I do that without creating entriely separate packages? Right now if I upload a package using our versioning but following your feed requirements I cannot do this since they get pushed as 1.0.0 in both cases.

Why make a Universal feed so restrictive? It's supposed to be Universal isn't it?

Product: ProGet
Version: 4.6.3

jstarbird_7831

I found a possible solution, looks like the Jenkins add-on for BuildMaster is now handling the metatdata in the version string. However, when I upload a package to the universal feed as 1.0.0+29 and then upload another as 1.0.0+30 the feed shows 1.0.0+29 as the current package and I have to go into the Full Versions list to see the newer packages, but even then I cannot select any of the other versions listed like I can in other feeds.

Is this a bug?

jstarbird_7831

I'm going to submit a bug on this as there is also an issue with Deleting a package from a Universal feed when there are multiple versions of the package.

The "Deployment" feeds were NuGet packages, so of course, you can still create a NuGet feed. However, those are intended only for .NET/C++ library files, and aren't great for application packaging.

A "universal package" is more a standardized shipping container that can fit just about anything... but it still needs to have some explicit rules to be remotely useful (otherwise, it would just be a share drive with free-form files). For the version number, we decided to use the widely-used SemVer instead of developing a proprietary versioning scheme.

The "+" syntax is for "build metadata". Note from the specs:

... Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85...

So it's behaving as expected, I think. You could also use "-" field (which is for pre-release data), but that isn't really designed for your usecase either.

Otherwise, if you can't change your versioning scheme, you'll have to find a way to creatively fit your application in the "box". You could use package metadata to have the "true" version number. If the major version hardly ever changes, you you could always just use the last three parts of your version number.

You could overload the major/minor version, so like...

4.2 --> 10402
9.13 -> 10913
12.83 -> 11283

I do see your ticket, so we will look at the bugs/behavior in further detail.

jstarbird_7831

that's a good suggestion I might be able to use that with some other adjustments.

Is there someway to make a copy of my previous Deployment feeds? The configuration of those feeds fit my needs perfectly.

Another question, sort of related, there is the concept of Groups when I'm uploading to Proget but I can find no use for it on the Proget server, is there someway within the Web UI to sort or show the groupings?
I see Tags in the feeds which seems to correlate but I cannot filter to only see the packages for a particular tag either.

They were really just NuGet feeds with a different logo... so you can create a NuGet feed to have the same usage.

"Groups" are used by some package types (Maven, Universal), but they are effectively just part of the package identifier, and are used for searching via the API. The ProGet UI does not display them any differently, but a consuming application might.

jstarbird_7831

Thanks for clarifying that about the Nuget feeds. Awhile back I understood the behavior had been changed so new Nuget feeds did not function the same way.
It was a discussion related to Jenkins so I may have misunderstood where the change was.