| The reason for this problem is complex. The simple version is that we don't just import the DSC resource directly from the PowerShell Gallery, we run it through a build process that repackages and vendors it into a Puppet module along with helper functions. Sometimes we have to make updates to the tool that does that build process, and when we do that, we need to rebuild a new version of the module. We can't just republish the same version number of the module, because there be dragons, so we have to distinguish between and rank builds. We chose to do that via pre-release numbering (version-prerelease (see below), so the referenced dsc-psdscresources-2.0.0-0-3 module is the third build of the psdscresources v2.0.0 DSC module. So why did we use prerelease instead of the build identifier (version+build)? Because semver explicitly discards the build identifier when comparing versions, so dsc-psdscresources-2.0.0+0-1 = dsc-psdscresources-2.0.0+0-2 = dsc-psdscresources-2.0.0+0-3. So this still doesn't let us have a "latest" version. Correcting this means fixing semantic-puppet such that it compares pre-release versions properly. The problem is in the assumption made with the first bullet point of https://github.com/puppetlabs/semantic_puppet/pull/23. If you specify the range as described, it does work according to that design requirement. I believe that is incorrect.
> SemanticPuppet::VersionRange.parse(">= 2.12.0-0") === SemanticPuppet::Version.parse("2.12.0-0-4") |
=> true
|
Related: we also need to iterate on the release numbering anyways, since this scheme will break as soon as we get to double digits. dsc-psdscresources-2.0.0+0-2 will sort lexicographically as greater than dsc-psdscresources-2.0.0+0-12. Tangent: During development, we also specifically chose to require version pinning, since the ecosystem was more volatile than usual. That's no longer the case though. |
