No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

Hey there, I recently submitted an <https://github.com/pulumi/pulumi/issues/17415|issue> and a fix was released into the pulumi go sdk on `v3.212.0` .  I'm struggling with the same <https://github.com/pulumi/pulumi/issues/18384|issue> this person had at the begining of the year - where even though the latest release of the SDK has my fix, sdks are generated via `pulumi package add terraform-provider ...` referencing an older version in the `go.mod` file that does not have my fix. This results in needing to communicate additional steps to developers for local development or having ad-hoc steps during CI

Thoughts on patching the codegen tool to bump the version of the sdk in the go.mod file to `v3.212.0`?

I think last time we discussed that we were hesitant because it forces everyone to update, even when not needed. Might be more palatable to add something to the schema so this one provider can opt-in to a later version. Can you raise an issue about it, getting close to Christmas holidays and might get missed if its not recorded.

Yeah totally get it. It would be cool to support a new flag to specify the version of the sdk to use in the generated mod file `pulumi package add terraform-provider foo/bar 1.2.3 --sdk-version=3.213.0`

Alright I submitted an issue <https://github.com/pulumi/pulumi/issues/21290|here> - but this has sparked a larger discussion (mainly with myself :sweat_smile: ) as to the _right_ way. Perpetually bumping this hard coded value doesn't seem scalable - and also has the potential to introduce breaking changes to existing CI processes using `pulumi install` .