Hi, Thank you in advance for your assistance. I am in the process of integrating the Pact framework into my company's workflow. Having reviewed the architecture, I fully appreciate its benefits. However, there's an aspect I'm struggling to grasp, and I would greatly appreciate your guidance on it. Our architecture follows a standard client (CLI) and server structure, and I am keen on incorporating a contract testing layer into our build process. The publishing of contracts is intended to occur after a merge event, with both consumer and provider tests running in their respective builds (which are in different repositories and utilize different programming languages). Currently, the API is used internally (without external API integration), allowing for API changes if both sides agree. Though contract testing is primarily advantageous for scenarios where one side changes without informing the other, this setup seems fairly standard to me. We operate on a quarterly release cycle and maintain hotfix branches derived from the previous release. From what I understand, provider tests are typically conducted against the most recent contract. However, with a hotfix branch, the provider version lags behind the latest consumer version. I can see how this setup might work for non-breaking contract changes, but our situation involves potential breaking changes. I hope my explanation is clear, and I look forward to your advice on how to navigate these challenges.

The main flaw in that reasoning is verifying against the most recent consumer. Whilst you can do that it's not recommended (for essentially the reasons you are concerned about).

thanks for your answer, I will read and let you know if it still not clear

If it's on the provider, you're merging into the release branch. The consumer target is the same. But in general, WIP pacts is how you validate unknown consumer branches/changes from the provider. See the linked CI/CD workshop also for a practical example of that

I thought about a solution, let me know what do u think. • I will use a selector, so each consumer merge branch will publish with branch version/tag (maybe the term is not correct) • in the provider test, it will choose the pact by the selector (consumer branch) • provider could choose easily when to go to the next pact (by the branch) • when an hotfix would be derived, it will have its stable pact (because in the past it was stable, so it will interact with an old pact) • The only disadvance, for each new consumer, I need to update the provide to select the new pact, for a new test, is not an issue, but for update the current API, I need to update the provider as well (I know there is the WIP feature, but I don't know how it will help me with the hotfix scenario) would like to get your feedback

• The only disadvance, for each new consumer, I need to update the provide to select the new pact, for a new test, is not an issue, but for update the current API, I need to update the provider as well (I know there is the WIP feature, but I don’t know how it will help me with the hotfix scenario)

WIP pacts verify all of the latest new pacts from unknown (consumer) branches and verify them. If there is a consumer hotfix branch, it would verify that also

but the idea, the hotfix is derevied from the previous release, so I think the WIP will not help here. beside that, do u see any issue with my suggestion?

It seems like a decent starting point. I always advise to start simple and improve, rather than to over complicate things too early

seems for the first iteration it is working like a charm, thanks for your help

Great!