Hey. I was watching the and @Beth (pactflow.io/Pact Broker/pact-ruby) said the recommended approach is for the consumer to code against new functionality on a feature branch so it doesn't break the provider. I totally get why this approach solves the problem of not introducing a contract into the main branch until it's ready to go live. However, this pretty much goes against trunk-based development. This is a key practice that has been shown to improve software delivery performance (see the book Accelerate). For reference you can see the DORA page on trunk-based development as well as https://trunkbaseddevelopment.com/ It's great that pending pacts helps solve this, but I am concerned in general that as you develop tools and features for Pact, you're assuming a workflow that actually isn't best industry practice these days. For example, an important workflow we need to support is to put new changes behind a feature flag. We want to test the new pact that's behind this feature flag without causing the provider to have their build break now that the pact has been verified (which is what would happen with pending pacts). I think we can do this with tags (need to try it) but I'm concerned you're moving away from tags to the concepts of branches, deployments and features. In that world, there is no space for scoping a pact and its verification based on a feature flag. I'd love to hear your thoughts on this. Thanks!

There are a few flavours of trunk-based, the one I see most often is very short-lived feature branches. I think might be the best-practice assumed workflow, or you need compile-time feature flags to not break the trunk.

Yeah, even the guide above has PRs that are attached to a branch (and, if not a branch, something conceptually identical to one)

Yea, but those are short-lived branches, like a day. In teams that are really good about delivering functionality in small chunks, an API change could go out in a day. But in other teams/orgs this is not the case, and generally the consumer will want to push out their changes even while the provider is still working on their side.

I don’t think Pact takes a position on the lifetime of a branch, but perhaps you’re suggesting as a result of having branches as a concept it might result in longer-lived branches as a consequence?

Long-lived feature branches are really problematic; this is not just theoretically true, I still have scars on my back from teams that have done this

haha yes, most of us have!

I don't see how you can recommend keeping a new API change on a branch without it becoming a long-lived branch

right, in that case you can definitely toggle (I do think we have some docs on that).

Oh that's great. I couldn't find any

Haha thanks. Sometimes search just doesn't work

no, I don’t think we’re looking to remove them

Ok, well that's good. I think I've made my point and I will stand down 🙂 Realizing, reading your docs, that the same git sha is actually different versions of the consumer depending on which set of flags are toggled on or off. 🤔

bag of tags

🤣

Yea, it's actually an incredibly common anti-pattern. A developer says "we don't know what the schema is, so we just implemented a table with key column and a value column. It's so nice and flexible!" I go 😱 and explain the problem with what I call a "bag of flags"

Yes, it’s also “very flexible” - what could be bad about that?!

yeah, "bag of tags" is usually a workaround for "we don't know what we/you want/need yet" 😅