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

<https://github.com/pulumi/pulumi/pull/13800> another breaking change, this time hurting the community building pulumi providers
can we have an open discussion on how to improve communication on changes to the pulumi ecosystem ?

This was recently discussed in <https://pulumi-community.slack.com/archives/C04NPQTRKM4/p1694553850357439>

I wouldn’t call that “discussed” :slightly_smiling_face:
obviously it didn’t reach all the package authors
perhaps an email blast?

there was also this <https://github.com/pulumi/pulumi/issues/13916> which almost resulted in a destruction of an entire stack

the more I invest myself into pulumi the more I become aware of the rapid breaking changes

I don't think we have every package authors email. Our best channels are github release notes or the channels here.
13916 hasn't yet been investigated by us so I can't comment on that yet.

I follow the releases, but this was releases as a minor update - although it’s a breaking change

Hi Omer thanks for the callout! This is indeed an area we can do better at.

We're having some discussions to figure out better comms on this, both proactively communicating breaking changes and retroactively communicating unexpected breaks (this one was unexpected to us internally).

We don't follow semantic versioning for pulumi releases. tfbridge and providers might, but the core product is stuck on major version 3 even if we have breaking changes.

<@U02J3T6A8LB> so how do you expect users to follow upgrades? is there any documentation on your versioning scheme?

right now we hope to periodically auto upgrade minor updates if all tests pass, and manually inspect major updates
do you suggest we manually inspect every minor update?

&gt; is there any documentation on your versioning scheme?
I'm not sure if it's publicly documented but we follow a system of bumping the minor version if there's any changes to features, and the patch version for just bug fixes.
But yes currently you need to manually inspect every minor update. We _try_ to call out breaking changes in the release notes, although in this case we didn't notice it was breaking till after it had gone out.