Hey folks, quick question, how do you guys are managing your versioning of your resource libraries?

I’ve simplified my setup to use a mono repo of infra and apps with standard devops practices. I don’t manage any of the infra differently from the source to my apps. I don’t use versions, just the commit sha and a date to track where a change comes from. This also forces every stack to use the latest, so we write the builders to mostly be stable in that you have to enable new functionality, unless it’s a requirement for security or a platform decision to enable everywhere. Not 100% I answered your question, but maybe it’ll help anyway.

I see, however is this really what you want

forcing every stack to use the latest

(yes, eventually, it should be but I think it doesn't work in the flow like this), like, let's say, I'm implementing a new feature at stack called

network

, enabling

vpc flow logs

and let's say I bump the minor version for enabling a new feature. If I version the codebase of each stack, and have a pattern to orchestrate them(let's say that's the main pulumi program, or ci/cd itself, I'm not sure yet), It will be simply as just increasing the minor version of the codebase. And then I can enable this new version at any environment in gradual steps(with a pulumi program that acts as an orchestrator or with CI/CD flows). I also keep a changelog so I can get a better understanding of what happened-when. However, if I just follow the latest commit sha, when I update the code base If someone is working on changing something(maybe bringing last changes to preprod that he/she made yesterday in dev) at pre-prod within the same stack. So he/she will see my changes as well, and he/she will need to stop his/her flow and start to work on what the actual hack is going on there. This is why I asked this question. It's kind of helped to but yes, not 100%, but thanks though 🙂

There are always trade offs between the two approaches. What makes it work for us is that we aren’t that big (under 50 devs) and we use this same pattern for shared code in applications. Any point in the mono-repo is the code to describe the infra, the apps and the configuration and can be deployed as test or prod. I know this solution doesn’t scale infinitely, but it removes a lot of potential for errors.

I understand your point. It does make sense for your case. Thanks @full-hydrogen-5950

Even if you use versioned dependencies, I’d recommend that they should lock to the major version and ensure that changes to minor version doesn’t change behavior without additional configuration. Any deviation from locking the major version should be tracked in a ticket so you can move everyone to use the latest released version as quickly as possible. Just my 50c

I was using release-please for these specific cases. It follows conventional commits so it was automatically bumping the version depending on the commit and pr title I've used. Expects

fix

,

feat

as prefix. There are some others though. So everyone is following a standardized way to version modules. If there is a breaking change then using

feat!:

is just enough to make bot to bump major version, including keeping the changelogs. I think I will need use this bot again.