chore+docs: uv.lock for 4.23.0, and_cross sweep, and the v1-39 OpenAPI pin - #514
Merged
Conversation
pyproject.toml was bumped to 4.23.0 while that version was tagged but not yet published, so the lockfile could not be regenerated at the time and kept resolving 4.22.0. Every workflow that runs a bare uv sync failed at dependency install as a result. 4.23.0 is now on PyPI, so the lockfile resolves.
There was a problem hiding this comment.
Orca Security Scan Summary
| Status | Check | Issues by priority | |
|---|---|---|---|
| Secrets | View in Orca |
The keyword-search concepts page still listed two search operators and asserted, as a general truth, that query tokens spread across different properties cannot match. Core v1.38.8 added a third operator that exists precisely to match tokens across properties. - Add and_cross to the operator list, with its tokenization/analyzer constraint and an "available from v1.38.8" qualifier, matching the phrasing already used on api/graphql/search-operators.md. - Reword the lead sentence to match search/bm25.md and search/hybrid.md, so "within a single searched property" describes what an operator can require rather than what all operators require. - Keep the worked example but scope its cross-property claim to `and`, and note that the same object does match under and_cross. Plain `and` is unchanged and still per-property; this is an addition, not a behaviour change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Follow-up to 9cc115e, which fixed only the keyword-search concepts page. - concepts/search/hybrid-search.md listed the operators as "and or or" in a passing mention of the BM25 parameters hybrid search inherits. Name and_cross alongside them and link the phrase to the concepts section that carries the semantics, keeping the mention at its original depth. - search/hybrid.md named and_cross under the shared "Added in v1.31" note with no qualifier of its own, so a v1.38.8 operator appeared to date from v1.31. Add the inline "(available from v1.38.8)" form used on api/graphql/search-operators.md and on the concepts page. The two-operator claim now appears nowhere under docs/. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The interactive REST reference (@scalar/docusaurus at /weaviate/api/rest)
was still pinned to the curated v1-38/openapi-for-docs branch. Bump the
ref to v1-39/openapi-for-docs, which carries info.version 1.39.0.
Verified by fetching the exact URL literal from the config: HTTP 200,
412645 bytes, valid Swagger 2.0. Against the 1.38 spec it adds
/search/{collection}/near-text, the namespace suspend/resume pair and the
property index rebuild/cancel pair, and drops
/schema/{className}/indexes/{propertyName}.
This pin is not covered by _build_scripts/update-config-versions.js, which
only rewrites versions-config.json, so it is a manual per-release step.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Four commits from the final 1.39 sweep. All small, all independent.
uv.lockfor weaviate-client 4.23.0.pyproject.tomlwas bumped while 4.23.0 was tagged but unpublished, so the lockfile kept resolving 4.22.0 and every workflow running a bareuv syncdied at dependency install. 4.23.0 is on PyPI now.and_crossadded to the BM25 concepts pages.concepts/search/keyword-search.mdstill listed two operators and asserted, as a worked example, that tokens spread across properties cannot match. That is specific toand, not to BM25.concepts/search/hybrid-search.mdcarried the same two-operator claim. Both corrected, andsearch/hybrid.mdgained thev1.38.8qualifier it was missing. A three-pass sweep confirms the claim now survives in five places, all correct.REST API reference repointed to the v1-39 spec.
docusaurus.config.jswas pinned atv1-38/openapi-for-docs. I createdweaviate/weaviatebranchv1-39/openapi-for-docsby mergingv1.39.0into the curated 1.38 spec branch and verified the raw URL serves Swagger 2.0 atinfo.version: 1.39.0, 77 paths.Worth knowing
The 1.39 REST spec is not purely additive.
PUT /schema/{className}/indexes/{propertyName}is removed, replaced byPUT /schema/{className}/properties/{propertyName}/index/{indexName}with new/rebuildand/cancelsub-resources. I checked everyapi/rest#deep link in the docs: none targets the removed endpoint, so nothing dangles. But the endpoint disappears from the reference with no doc trail.This pin is the only Weaviate version reference in the repo that no automation touches.
update-config-versions.jsauto-correctsversions-config.jsonand nothing else, and no release checklist mentions creating thev1-XX/openapi-for-docsbranch or repointing this config. That is the mechanical reason it was missed for 1.39.Not fixed here
The
bm25_operatorsdiagram on the keyword-search page still shows two operators. It is a raster asset and needs a design pass.