There is no scheduled workflow in this repository. Every job runs on a push, on a pull request or on a
dispatch, so every fact this repository keeps about the world outside it is refreshed when somebody
remembers to refresh it.
Three of those facts are already known to decay, and both open release issues list regenerating them as
manual work before a tag: the Qdrant compatibility matrix in the README, the comparison benchmark in
benchmarks/README.md, and the pinned OpenAPI document that M60 is about to turn into a release-time
check. A table that is a fortnight old is a small problem. The real one is the version behind it:
Qdrant 1.19 shipped on 4 August, and this repository found out because a person read the release notes.
Tier 10 exists because of what that release added, and it started when the reading happened.
A weekly job that runs the shared client contract against the newest released Qdrant tag turns that into
an observation. Most weeks it costs a runner and says nothing. The week the answer changes it opens an
issue naming the version and the cases that failed, which is the trigger the last two tiers were opened
by hand.
Two things to settle while doing it. Whether it opens an issue or a pull request carrying the regenerated
table, given that a table is mechanical and a failure needs a person. And whether a weekly run does the
whole contract over both engines or the part that is cheap enough to run unattended, because a job that
takes twenty minutes every Monday is a job somebody eventually deletes.
Exit criterion: a scheduled workflow runs the shared client contract against the newest released Qdrant
and reports a change by opening an issue that names the version and the failing cases, demonstrated by
pointing it at a version known to fail rather than by waiting for one.
There is no scheduled workflow in this repository. Every job runs on a push, on a pull request or on a
dispatch, so every fact this repository keeps about the world outside it is refreshed when somebody
remembers to refresh it.
Three of those facts are already known to decay, and both open release issues list regenerating them as
manual work before a tag: the Qdrant compatibility matrix in the README, the comparison benchmark in
benchmarks/README.md, and the pinned OpenAPI document that M60 is about to turn into a release-timecheck. A table that is a fortnight old is a small problem. The real one is the version behind it:
Qdrant 1.19 shipped on 4 August, and this repository found out because a person read the release notes.
Tier 10 exists because of what that release added, and it started when the reading happened.
A weekly job that runs the shared client contract against the newest released Qdrant tag turns that into
an observation. Most weeks it costs a runner and says nothing. The week the answer changes it opens an
issue naming the version and the cases that failed, which is the trigger the last two tiers were opened
by hand.
Two things to settle while doing it. Whether it opens an issue or a pull request carrying the regenerated
table, given that a table is mechanical and a failure needs a person. And whether a weekly run does the
whole contract over both engines or the part that is cheap enough to run unattended, because a job that
takes twenty minutes every Monday is a job somebody eventually deletes.
Exit criterion: a scheduled workflow runs the shared client contract against the newest released Qdrant
and reports a change by opening an issue that names the version and the failing cases, demonstrated by
pointing it at a version known to fail rather than by waiting for one.