Universal Packages with build numbers not working

kc_2466

ProGet Free Edition - v2024.36 (build 5)

I'm having trouble using build numbers in the version of Universal Packages in Proget.
The Symantic Version spec https://semver.org/ suggests I should be able to add "+" <build> to a version number. However if i create packages with build numbers, they seem to overwrite previous packages of the same version (but different build number) - and the build number doesn't show up anywhere in the UI.

Alternatively i've tried creating packages with the version format w.x.y.z - which is not permitted through the create package UI, but PGUtil allows. This mostly works, except that the sorting doesn't work correctly when you list the packages (it works correctly for x.y.z style versions).
Even though this version convention doesn't meet the semantic version spec - it would be good it it continued to work, as i've now migrated all my data using this format, as the +<build> didn't work.

stevedennis

Hi @kc_2466,

SemVer build numbers are really weird -- they are not intended to make a version unique. In other words, 3.4.1+1 and 3.4.1+2 are considered equal, and thus overwrite them.

As for 4-part numbers, that is most definitely a validation bug - Universal Packages use SemVer, and 4-part versions are invalid. Now that we know about it, we will likely fix it - so don't use it.

I'm not totally sure what you're trying to accomplish, but the best CI/CD workflow for builds and releases is to use prerelease/repackaging:
https://docs.inedo.com/docs/proget/packages/repackaging

If, for whatever reason, your package needs a version number that SemVer does not support, you can do something like yz = y*100000 + z*100. For example, 4.2.1.5 becomes 4.2.100500

Thanks,
Steve

kc_2466

@stevedennis - I'm migrating items from another system, and we do use 4-part version numbers (where the 4th is the build number). But we don't want it to ignore the build number part. Combining parts 3 and 4 isn't very pretty, and won't give a very good first impression of ProGet to my users if I say that that's not supported.

I'll look into going do the -ci.xxx route - I assume it will order them alphabetically rather than numerically though - so i guess i need to pad them with 0's to the maximum likely width.

stevedennis

Hi @kc_2466,

Prerelease segments are sorted numerically, so 1.0.0-ci.10 > 1.0.0-ci.2 as you would expect.

If most builds are never released to production (a common CI/CD scenario), this is a great approach.

Thanks,
Steve

kc_2466

I've just used "pgutil packages repackage" to change the versions on all my erroneously versioned packages from w.x.y.z to w.x.y-ci.z.

I was expecting only to see the newly versioned packages, but in fact i now have both versions listed - is this the intended / expected behaviour?

Also, i'm not seeing anything in the history tab to show that the package has been repackaged. But I can see the 'repackageHisory' in the upack.json.

ProGet version 2024.36 (build 5) - Trial license (Basic Edition Features)

stevedennis

That's the intended/expected behavior of repackage. The use case is CI/CD workflows, so you would do something like:

Create w.x.y-ci.z
Repackage to w.x.y-rc.z
Repackage to w.x.y

Retention policies would then clear out old -ci and -rc packages.

I believe that display bug has been fixed in ProGet 2025; I remember seeing it listed as a bug discovered during testing. But in any case, it's in the package history as you can see.