kdrant-cli ships a Linux and a macOS binary. kdrant-cli compiles for mingwX64. Those two sentences
sit in the same release and the second one is not doing anything for anybody.
The reason it stopped there is not a decision, it is that 2.2.0 had a Windows target that built and no
runner attaching it, and the exit criterion named the two platforms CI already had. Either the Windows
binary joins the release, or the target comes out of the build file, because a target that compiles and
is never shipped is a compilation that costs time and proves nothing.
The rest of the milestone is the half of the CLI that was cut rather than declined. kdrant snapshot
covers a collection's snapshots and not the shard-scope ones or the whole-storage ones, which is a gap
somebody restoring a large deployment meets immediately. kdrant collections lists and does not create,
delete or describe. There is no kdrant health for the three probes, which is the first thing anybody
types at a node that is misbehaving and the reason the tool exists.
What stays out stays out for the reason already written down: this is not a query tool, because Qdrant's
dashboard is better at that and is already running next to the server. Adding kdrant search would be
the first step to a worse copy of something that exists.
One thing to decide rather than assume: whether the binaries are worth a package manager. A Homebrew tap
and a Scoop manifest are each a small file and a small ongoing obligation, and a curl from a release
URL is what the README documents today and what most people will use anyway.
Exit criterion: a Windows binary is attached to the release with provenance and a checksum, or the
mingwX64 target is removed from kdrant-cli with a decision note; and kdrant health, the shard and
storage snapshot commands, and the collection lifecycle commands each run against a real Qdrant in CI.
kdrant-cliships a Linux and a macOS binary.kdrant-clicompiles formingwX64. Those two sentencessit in the same release and the second one is not doing anything for anybody.
The reason it stopped there is not a decision, it is that
2.2.0had a Windows target that built and norunner attaching it, and the exit criterion named the two platforms CI already had. Either the Windows
binary joins the release, or the target comes out of the build file, because a target that compiles and
is never shipped is a compilation that costs time and proves nothing.
The rest of the milestone is the half of the CLI that was cut rather than declined.
kdrant snapshotcovers a collection's snapshots and not the shard-scope ones or the whole-storage ones, which is a gap
somebody restoring a large deployment meets immediately.
kdrant collectionslists and does not create,delete or describe. There is no
kdrant healthfor the three probes, which is the first thing anybodytypes at a node that is misbehaving and the reason the tool exists.
What stays out stays out for the reason already written down: this is not a query tool, because Qdrant's
dashboard is better at that and is already running next to the server. Adding
kdrant searchwould bethe first step to a worse copy of something that exists.
One thing to decide rather than assume: whether the binaries are worth a package manager. A Homebrew tap
and a Scoop manifest are each a small file and a small ongoing obligation, and a
curlfrom a releaseURL is what the README documents today and what most people will use anyway.
Exit criterion: a Windows binary is attached to the release with provenance and a checksum, or the
mingwX64target is removed fromkdrant-cliwith a decision note; andkdrant health, the shard andstorage snapshot commands, and the collection lifecycle commands each run against a real Qdrant in CI.