This repository was archived by the owner on Feb 24, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on Feb 24, 2021. It is now read-only.
DSC Resource Kit modules should use Semantic Versioning #508
Description
DSC resource kit modules should use semantic versioning. There are issues when using non-semantic versioning and newer versions of NuGet.
NuGet will normalize versions to be semver, in DSC case removing the trailing zero (2.3.0.0 to 2.3.0). This will create a mismatch between the psd1 and module version folder causing Import-Module to fail loading the module.
I run into this issue when replicating DSC resource kit modules from PowerShell Gallery to my company's internal Artifactory repository.
Please refer to PowerShell/PowerShellGallery#55 for more information.
Activity
gaelcolas commentedon Jun 3, 2019
Hi @tnieto88,
Thanks for the feedback.
I'm keen to use SemVer for many reasons, as long as we keep the NuGet compliant format for pre-releases.
Ideally, in my opinion, we'd use something like
gitversionto consistently version our releases.The problem here is that it's quite a bit of a change on our current release process, so it'll take some time to transition.
We're already looking at ways to make the release process a bit more transparent so that the community can contribute.
Stay tuned! ;)
ThomasNieto commentedon Jun 10, 2019
gaelcolas (@gaelcolas) My main concern is that DSC resources are using four digit version with a 0 in forth position. NuGet will normalize that version that to a three digit version number causing the module manifest and package version not to match. For more information about NuGet version normalization: https://docs.microsoft.com/en-us/nuget/reference/package-versioning#normalized-version-numbers
To resolve this issue the DSC modules will need to use a three digit versions that will not get normalized. From what I've seen in the last year of releases DSC resources never uses the fourth position so it shouldn't be an issue migrating from four digit to three digit version.
KevinMarquette commentedon Jul 9, 2019
The core issue driving this issue in nuget here: NuGet/Home#3050
Either drop to a 3 part version number or place anything except 0 in the 4th part. This will mitigate a lot of frustration for people trying to use an internal PSRepository.
PlagueHO commentedon Jul 12, 2019
I reckon we're going to need to get a fix for this sooner rather than later and drop the trailing number if it is a 0 when publishing/deploying as Kevin Marquette (@KevinMarquette) says. This will require modifications to the publish scripts that Katie Kragenbrink (@kwirkykat) wrote, but I don't see that is a major problem - should be a simple change. But it will mean the resources drop the last digit in the PS Gallery (because they're always a zero).
Johan Ljunggren (@johlju) , gaelcolas (@gaelcolas) - do you see a problem with us doing this before the next release? Would need to run it past Katie I'd think.
johlju commentedon Jul 12, 2019
I have no issue with changing, but what happens when users run
Update-Module? Will it see it as a new version if existing modules are present? Will it see3.1.0as higher than3.0.0.0? 🤔ThomasNieto commentedon Jul 17, 2019
Johan Ljunggren (@johlju) PowerShellGet does a version comparison so
3.1.0is newer than3.0.0.0.StingyJack commentedon Sep 24, 2019
@tnieto88 - it only removes the trailing zeros and some leading zeros. So you can have a 2.3.0.1, but it will change your 2.03.0 or 2.3.0.0 to 2.3.0.
It would be great if this group does not make the same mistakes that the NuGet team has made in this regard. The intention for version normalization in nuget was to make it easier for nuget.org to sanely deal with package versions on such a massive scale. The mistake was that it should have only been made a requirement and filter for packages published to that repository and others that elect to impose that restriction. It should not have been forced on every non-public nuget repo by changing a value the program is expected to take verbatim.
If you like irony, in the case of NuGet, they are trying to coerce a flavor of SemVer and knowingly introduced a breaking change to do it, but did not update the major version number (which SemVer dictates should happen).
KevinMarquette commentedon Sep 25, 2019
How is the DSC Resource Kit published so that the 4 part version is showing up correctly in PSGallery? The core issue here is that Publish-Module is using NuGet and NuGet is packaging them in a different way.
johlju commentedon Sep 28, 2019
The modules are released using the version in the module manifest which is using 4-part version. It’s a manual process where most likely
Publish-Moduleis used.In the first module automatically released in DSC Community https://github.com/dsccommunity/GPRegistryPolicyDsc we switch to using 3-part version number.
KevinMarquette commentedon Sep 30, 2019
I was only asking about publishing because
Publish-Moduleis handing the work off to nuget. The publishing process must be using a down level version of nuget to preserve the 4 part version number for the gallery.johlju commentedon Oct 1, 2019
Kevin Marquette (@KevinMarquette) Ah, now I understand what you meant. Meaning we could have an issue deploying 4-part in the future if
Publish-Moduleswitches to a newer version of nuget? 🤔KevinMarquette commentedon Oct 2, 2019
More specifically, if the system running
Publish-Moduleupdates NuGet then you will also have this issue.Publish-Moduledoesn't pin to specific version and that is why people are running into this issue. IfPublish-Modulewould handle it, then nobody would have the issue.johlju commentedon Jan 15, 2020
All modules transferred to DSC Community can now be converted using the new CI pipeline which uses semantic versioning. Community has already converted some.
https://dsccommunity.org/blog/convert-a-module-for-continuous-delivery/