Generalise how package version isn't stabilized for dev/preview stages #5640
Conversation
There was a problem hiding this comment.
Thank you so much for the help with this @RussKie! this is great. Given these properties could be impacted by race condition, can we also add a target that runs after GenerateNuspec that validates that version contains a prerelease label?
|
Also, I'm assuming you did, but in case not you should be able to validate if this works by running |
This command doesn't work (don't ask me how I know). The following do: I added a pack-time check to ensure the version suffix is correct: |
| --> | ||
| <SuppressFinalPackageVersion /> | ||
| <SuppressFinalPackageVersion Condition="'$(Stage)' == 'dev' or '$(Stage)' == 'preview'">true</SuppressFinalPackageVersion> | ||
| </PropertyGroup> |
There was a problem hiding this comment.
Version suffix calculations are performed in Version.BeforeCommonTargets.targets, which too late for the functionality placed in eng/MSBuild/ProjectStaging.targets
Arguably, we could add eng/MSBuild/ProjectStaging.props, but it feels more logical to have versioning-related configurations in one place (which is here).
There was a problem hiding this comment.
Will Stage be defined this early though?
There was a problem hiding this comment.
Oh, I see it will because you are creating a Directory.Build.props everywhere to make sure you control the order of imports. While that would work, I'd argue that we are probably defeating the point of the benefit of the change. The initial motivation was to simplify things, and reducing 2 lines in projects (setting the stage, and setting suppressFinalVersion) to a single one, but this is instead now making us having to add new files per project, and it also means that now you need to know to look into this file to see if a package is stable or not and also to know what is the stage.
Thoughts?
There was a problem hiding this comment.
Probably an even more meta question (sorry for having this discussion in your PR) is: do we even really need package stages? What benefit are we getting out of them? if it is literally just that the description has a few other words as a prefix, then perhaps we should just have stable and unstable packages, and adjust the descriptions of packages accordingly. That way, we can go back to having a single property in the package that marks it's "stableness"
| Makes it such that the package version won't be stabilized even when the rest of the repo is going stable. | ||
| https://github.com/dotnet/arcade/blob/main/Documentation/CorePackages/Versioning.md#package-version | ||
| --> | ||
| <SuppressFinalPackageVersion /> |
There was a problem hiding this comment.
NIT: No need to unset it here as that is the default already.
| <SuppressFinalPackageVersion /> |
Follow up on #5632
Microsoft Reviewers: Open in CodeFlow