Hi - I'm getting confused about how pact broker figures out what the "latest" version of a pacticipant on a branch is. I had a situation where I was running pact verification tests using

[{"branch":"develop", "consumer": "foo"}]

as my consumer version selector, and the verification test indicated that it was using version

2.37.0

of the pact as the "latest version" from the

develop

branch of pacticipant

foo

. However if I ran this query against the pact broker db:

select p.name, b."name", v."number"  from branch_heads bh
	inner join pacticipants p on p.id = bh.pacticipant_id 
	inner join branches b on b.id = bh.branch_id 
	inner join versions v on v.id = bh.version_id 
	where p."name" = 'foo'
	and b."name" = 'develop'

it returned me the value

2.37.0-develop+5.cb7bd044

. (this was what I expected, as it represents the absolute-version of the latest commit on that branch, i.e. 5 commits on from the commit tagged with

2.37.0

) Would the pact broker be using some different logic internally when being asked for latest version on a branch that could explain this discrepancy? If I then republished the pacts again from the head of the branch, then the consumer version selector correctly returned

2.37.0-develop+5.cb7bd044

What (pact broker) version are you on Alan?

It's a version that getting a bit long in the tooth TBH -

dius/pact-broker:2.96.0.0

Yes. I recall at some stage, the ordering was either configurable or used a “semver” like ordering scheme

And everything observed kind of follows on from that principle, except the SQL query gets its "right" (at least from the semver ordering perspective).

It would be worth querying the relevant versions table to check the publication dates on the versions, that might make things a bit clearer

Just to explain a bit more - the version is a ""retrospective" release version, which happens when a previous git commit is tagged with

2.37.0

. At this point

absolute-version

reports the version to be

2.37.0

as expected and my release pipeline publishes the pacts from that commit with this version. Of course, due to the way

absolute-version

works, this in effect changes the version of the pacts currently at the "head" of the develop branch, because everything is calculated as an offset from the last release-tagged commit. e.g. if the version representing the head was

2.36.5+11

, and the release tag

2.37

is applied to the commit with version

2.36.5+7

, then the current head becomes "re-versioned" to

2.37+4

.

This is what I was looking for (there is a config to set it to order by date or semver, now deprecated)

So, while I'm not surprised some part of the system thinks

2.37.0

is the latest, I guess I was offered false encouragement that SQL returns me what I really wanted as the latest

2.37.0-develop+5

. That feels to me that something inside the pact broker is calculating the latest in a different way.

yes, probably. I can’t tell you the queries it uses but IIRC there are either tables or columns that calculate “heads” and “latest” things (and also there is this commit around ordering). So it’s probably more complicated. To find out what it’s doing, set the pact broker log level to TRACE (I think, let me confirm). It will log all SQL queries, so be warned, but you could try it out for a few minutes with a local broker or something to see the query

Thanks - the fundamental problem I think here is that

absolute-version

doesn't guarantee immutable versioning due to its offset-related behaviour, in that the same git commit can map to different versions over time as previous commits are tagged. So I guess I'm faced with two possible ways forward: • come up with some versioning scheme that is immutable, or; • continue to use

absolute-version

, but when a commit is retrospectively tagged with a release, come up with some way of telling the pact-broker "hey, what you thought was version X is now version Y" On the latter approach, I guess just republishing the pacts at the head of the branch after a retrospective tagging would suffice. But it would be interesting to know what others do who rely on

absolute-version

.

Yeah, that’s an interesting point. I think it’s a use case the original author of the library probably didn’t consider (not surprisingly). I can’t remember why semver was deprecated (probably there is some information in a commit/PR somewhere), but it probably was for good reasons - usually these things get deprecated because it creates sharp and pointy edge cases, code/performance more complex etc. But that’s just a guess. You could potentially enable it to see if it addresses the problem (but I would agree with assuming it’s not a great idea to switch)

Yeah I think that, given that semver ordering is deprecated, would be the equivalent of switching to a train that was headed in the wrong direction.