Description
.NET Framework Used:
- .NET 9.0
- Something else
OS Environment:
- Windows 10
- Windows 10 IoT Core
- Windows Server 2012
- Windows Server 2012 R2
- Windows Server 2016
OS Version: ####.####...
I have already...
- Reproduced the problem using the latest stable release.
- Reviewed the documentation.
- Reviewed the current issues to check that the issue isn't already known.
Description:
CI Versioning generated by this task are incorrect. It does not account for the "Patch+1" in any way.
Steps to reproduce the problem:
- Reviewed the documentation.
- Included Sample code or link to repository/gist to reproduce the bug (This is the fastest way to a resolution as it reduces the time to reproduce the problem. The smaller the sample is the better.)
Build a project with the following:
BuildVersion.xml
<BuildVersionData
BuildMajor = "5"
BuildMinor = "0"
BuildPatch = "4"
/>Expected Behavior
FileVersion: 1.27597.27643.9995 [This is 5.0.4 + CI] [Correct behavior]
ProductVersion: 5.0.5--ci.610628460.ZZZ [In SemVer terms that is a "prerelease" and ordered BEFORE a release of 5.0.5"]
Actual Behavior
FileVersion: 1.27597.27643.9995 [This is 5.0.4 + CI] [Correct behavior]
ProductVersion: 5.0.4--ci.610628460.ZZZ - [Incorrect behavior, CI build is now ordered BEFORE the release it is based on!]
ProductVersion is incorrect! In SemVer terms this is "pre-release" of 5.04 and therefore ordered BEFORE 5.04!
Additional context
It is debatable if this is a breaking change in the sense that it requires a new major version or not. The spec for this library defines what it is supposed to do but it does
not do that. But it does happily produce the incorrect version string. So, is it a breaking change or just a bug? (This is a core problem with SemVer/CSemVer as neither fully defines the concept. Ultimately ANY change, bug fix or otherwise, is technically breaking something that detected the previous behavior and depends on the broken behavior for logic. [It was wrong to do that but now it's broken...])