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

For example, AWS EC2 image builder recipes are designed to allow old versions to remain. When you make changes, a new version of the same recipe is supposed to be added.

In Pulumi, you don't _need_ to do this, since that's what your SCM is for: if you want an old version of your image, check out an old version of the code and run `pulumi up`.

But it would be quite nice to have those old versions tracked by Pulumi. But the only ways I can think of doing that are

1) Using automation-api to remove old versions from the state, so that Pulumi doesn't delete them, or

2) Keeping old image builder code in new Pulumi app code, and letting the state grow to include all verisons.

Option 1) means I can't easily delete recipes (since Pulumi only knows about the current version, and referential integrity will mean AWS refuses to delete the recipe until all its versions are deleted).