This message was deleted.

One weak point currently in 3rd party packages (providers + components) is keeping the Github Actions workflow files up to date with newer features/possibilities delivered by Pulumi. Pulumi (the company) keeps these files updated by generating them. All the code for that lives in https://github.com/pulumi/ci-mgmt. I'm working with the engineering team to have this setup working for 3rd party packages as well, not only for Pulumiverse, but also for some of our partners who maintain their package themselves. There is still some work to do to get there. The setup in

ci-mgmt

doesn't support the versioning scheme you propose, meaning that you can't benefit for what would come. Next to that, the language package registries (npmjs.org, pypi.org, ...) mainly accept a single

MAJOR.MINOR.BUILD

, each with their own semantics on version matching. Due to that, I want to advocate against this composite versioning structure. What I have seen done is keep

MAJOR.MINOR

in synch between the upstream and the bridged provider, but be liberal on the

BUILD

part.

gotcha, the package registries is a showstopper here really, so will take your approach with advancing just by patch

I would probably keep tabs on the version from the upstream provider, and bump the bridge provider version with the same major, minor, patch change (e.g. if 1.0.0 changes to 1.1.0 in the upstream, and the bridge is at 3.4.1, then bridge goes to 3.5.0). The upstream and bridge will obviously get unsynchronized, but that is probably fine and what you want. You should be able to break the bridge provider, even if the upstream provider does not and you probably want to communicate what the changes are regardless. Advancing only the patch seems dangerous, specially if the upstream breaks something. I’m not sure what consumers of the bridge provider needs to know the version of the upstream provider for, but if they do, maybe that’s something that should be added to the release log (e.g.

Update upstream provider to v1.2.3

).