Confusion versioning scheme

[dotMorten]

Describe the bug

For a while now you've used a versioning scheme which is [Major].[Minor].[year][month][day]00x, but you publicly talk about it as [major],minor].[releasenumber].
This has quite a few downsides:
It's much harder to just update your nuget package reference "by memory" because the version we talk about and the version we reference are completely different, and no one can remember the long version numbers. I've even seen Microsoft often get confused about which version is which release, like here and there's been several cases before in announcements/tweets/blogs:

I think it would make more sense to stop using year/date/month/number and just use plain old versioning that matches the release names, like you had it prior to v1.2. It's was simple, predictable and easy to understand, and it simplifies life for developers to understand where you are wrt versions relative to current releases.

From my understanding, the reasoning for this versioning scheme is purely an internal engineering thing (that should be easily overcome), and not a conscious decision around versioning nuget packages.

The ship has sailed for v1.5, since you're already released preview packages that would be seen as "newer" than 1.5.0, but perhaps consider this for the first 1.6.0 previews?

NuGet package version

Windows App SDK 1.5 Experimental 2: 1.5.240124002-experimental2

Additional context

Here's a slightly different way how MAUI does versioning, where only previews gets weird numbering:
https://www.nuget.org/packages/Microsoft.Maui.Sdk/
That might be useful when distinguishing experimental and previews

[kmgallahan]

The 2 you highlighted was a typo. #4194

I agree though that abandoning semantic versioning in late 2022 was a bad idea: https://www.nuget.org/packages/Microsoft.WindowsAppSDK/#versions-body-tab

Per: https://semver.org/ -

• Patch and minor versions MUST be reset to 0 when major version is incremented.
• Patch version MUST be reset to 0 when minor version is incremented.
• Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version.

[dotMorten]

The 2 you highlighted was a typo.

Yes I'm aware, and that was my point. I've seen this typo made many times over the last many releases in blogs, tweets, release notes and announcements, because they are just weird and having to deal with two version numbers for the same release is just plain confusing. The one I referred to was just the most recent one.

[stevenbrix]

omg @dotMorten you're my hero, i just came here to gripe about this

[stevenbrix]

also, there's no good way to tell from which version of the Framework Packages you have installed what you have on the machine

[DrusTheAxe]

• Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version.

Build metadata is informational. It has no bearing on identity, so it's not so interesting here.

[DrusTheAxe]

also, there's no good way to tell from which version of the Framework Packages you have installed what you have on the machine

Are you referring to Nuget or MSIX packages?

[davidair]

+1 on the issue of being unable to determine if a specific version is installed - I posted about it with detailed steps on https://stackoverflow.com/q/79216909/497403. Would love to at least see a workaround - is there a mapping between the version posted in release notes and one found locally?

For example, I’m looking for a bidirectional way to get between 1.6_6000.318.2304 and 1.6.3 (1.6.241114003) (I am assuming they are the same).

[tschbc]

+1 Would also like to see consistent versioning.