I have a package versioning format that goes like this:
PackageName.1.6.11.2101031341-release.zip [GOOD!]
The above uploads to Octo’s repo. However, the one below does not. All it does is bump up the major and minor versions and the first two digits of the date stamp go from 21 to 22 (since it’s now 2022), but through an octo API post or uploading it to the library in the UI, I get an error that says the semantic version cannot be parsed:
PackageName.1.7.1.2201031341-release.zip [BAD!]
Yet… changing the third dot to a dash IS acceptable to Octopus and will upload into the package repo:
PackageName.1.7.1-2201031341-release.zip [GOOD!]
What semver rule am I missing here? I’ve played with different numbers in the 0.0.0.date-release part, and I’ve seen 0.0.0.11xxx upload but not 0.0.0.22xxx, so some double digits work but others don’t?
Thanks for reaching out and I’m sorry to see you’re having issues with your packages.
I’ve been able to reproduce this and it does seem like there’s some kind of inconsistency in the way we’re handling SemVer 2.0. The first ‘good’ example appears to be the same SemVer as the second ‘bad’ example but is handled differently on upload.
According to https://semver.org/ neither of them are technically ‘valid’ as they have 4 dots before the dash, but appear to upload regardless, I believe this could be some kind of backwards compatibility we left in from previous builds.
I am going to reach out to our engineers for clarity on this issue, thanks for letting us know and I will get back to you when I hear something.
Thanks for your patience, and also for your report! I’ll jump in here for Garrett as he’s now offline as part of our US-based team, and we got an update from the engineers.
It looks like the root of this issue is when it tries to create the version, it returns an integer for each part of the version (major/minor/patch). Since the year got bumped to 22 the date string is past the limit of an integer (2147483647) so it fails to convert correctly. This is actually the same bug recently affecting Microsoft Exchange with the clock ticking into the new year.
Date values such as 2201010001 cannot be converted to long 32-bit integers, as they exceed the maximum of 2^31 or 2147483647 that can be stored.
This means that funnily enough 2147483647 succeeds, where changing 7 → 8, resulting in 2147483648 will not.
I’m hoping a quick and easy way forward, though certainly not ideal, is to cut a digit off the version to allow this component of the version starting with 22... to work, so as to keep it below that maximum.
I hope that helps somewhat, and please let us know how you go!
Thanks for the explanation, I was really scratching my head on this one.
When we push packages to Octo, changing the 3rd dot in the version to a dash gets around this issue. Is that because that dash makes Octo not consider it an integer? In any case, this small change is how we’ve fixed this when it comes to pushing packages to our Octo instance.
PackageName.1.7.1.2201031341-release.zip [This will get a “version can’t be parsed” error]
PackageName.1.7.1-2201031341-release.zip [This will upload to Octo’s repo just fine]
We’re seeing this issue in runs of msbuild with octopack=true arguments in some of our older build scripts. I’m guessing those are hitting against the same integer limit somewhere too.
Our version of Octo is 2019.13.7. Would this potentially be fixed in a newer Octopus version?
Just jumping in for Garrett as he won’t be on for a while.
When it tries to create the version it returns an integer for each part of the version. Since things after a dash are pre-release tags I believe the code is different there. This has been raised with our engineering team, but in the meantime as a workaround would you be able to do something like this?
PackageName.1.7.1.YYMMDD#-release.zip where # is an increment for the day?
