`PackageVersion` DateTime-Function in TileRepeater_Medium/TileRepeater.Package (and others) not chronological

[LukasGelke]

We are currently in the process of migrating our components to the new Designer.
After having the project on hold for some time, I've noticed, that the PackageVersion did not change. Reason being the Format String:

winforms-designer-extensibility/Samples/TypeEditor/Dotnet/TileRepeater_Medium/TitleRepeater.Package/TileRepeater.Package.csproj

Line 12 in 4959e7c

<PackageVersion>$([System.DateTime]::Now.ToString("1.yM.dHmm"))</PackageVersion>

> new DateTime(2025, 2, 5).ToString("1.yM.dHmm")
"1.252.5000"
> new DateTime(2024, 12, 23).ToString("1.yM.dHmm")
"1.2412.23000"

This results in the Version from December being considered "newer" by NuGet because 2412 > 252.
A better Format String might be 1.yyyyMM.1ddHHmm (or may be 2.yyyyMM.1ddHHmm, because the format changed? )

• made year component always four-digit and month, day, hour components always two-digit
• added a const '1' so 0-padded dates dont get truncated

> new DateTime(2025, 12, 23).ToString("1.yyyyMM.1ddHHmm")
"1.202512.1230000"

[MrMikeJJ]

@LukasGelke when I was messing around with version strings, I wanted them to line up and be useful. I.e. AssemblyVersion same as PackageVersion. etc.

So somethings I found doing that. Firstly, some stuff strips leading zeros from version numbers. Other stuff doesn't (Cannot remember what did it, just remember it happening.

Also for version numbers like that, certain parts have max values

255.255.65535.65535

So I went with something like this (trying to remember, may not be exact)

yy.M.d.Hmmr

(r being build revision number, something from Azure DevOps. builds in same minute increment it)

[LukasGelke]

@MrMikeJJ I get that PackageVersion==AssemblyVersion. It's very confusing if it differs when you have to debug/resolve problems. 100% agree.

But where did you get that limit from (ie. which part/location/mechanism/... imposes these)? Because using a version scheme based on date, where year is major (similar to ISO861 dates), this would not work at all. From memory it's not very prevalent in the DotNet world (because of "major may cause breaking changes" and other definitions). However 255 seems arbitrarily low.

at least yy.M.d. seems ok. But the last (Revision in System.Version) works only if r is only ever 0-9 (inclusive) and never null/empty, which depends on your build setup.

[MrMikeJJ]

@LukasGelke regarding version limits, https://learn.microsoft.com/en-us/windows/win32/msi/productversion

Hence why I went with yy. That will be valid for the rest of my life.

I only mentioned r for completeness, of what I use. Think that is pretty much tied to Azure Devops and the build agents. Where I work, 9 builds in the same pipeline and the same minute is not going to happen. I have only seen it go to 3 once. This was when I was testing the version stamping. In normal operation, it has never made it past 1.