docs: Weaviate 1.39 release - #479
Merged
Merged
Conversation
Remove the schema_tx metrics, which were deleted from core in 1.39. Promote the Boost API note from preview to generally available, and rename the now-misleading BoostPreview import alias to BoostNote across the five pages that render it.
In v1.39 the HNSW commit log compactor owns the full on-disk lifecycle of the vector index. Snapshots are always created and managed automatically, and the five PERSISTENCE_HNSW_SNAPSHOT_* environment variables are inert no-ops that log a startup warning when set. Docs serve the latest three supported minors, so the pre-v1.39 configuration guidance is retained and scoped to v1.31 through v1.38 rather than removed. - configuration/hnsw-snapshots.md: lead with the v1.39 behavior and the list of ignored variables; move the existing configuration reference into a section scoped to earlier versions. - concepts/storage.md: describe snapshots as part of the storage engine rather than an opt-in speedup, cover the streaming on-disk merge and the crash-safety mechanisms, and scope the previous conditional creation and snapshot fallback behavior to earlier versions. - env-vars/index.md: mark the five variables deprecated in v1.39 while preserving what they did for readers on earlier versions. - feature-notes/hnsw-snapshots.mdx: note the v1.39 change on both pages that consume the include.
The v1.39 crash-safety paragraph said a compacted segment that cannot be read in full is dropped in favor of the snapshot and the remaining clean segments. That is not what the loader does. For both raw commit logs and compacted .sorted/.condensed segments it calls truncateToLastValidRecord, keeping every record written before the corruption and leaving the file valid for later compaction. Only the damaged tail is lost. The two outcomes differ in recall, so describe the retention explicitly and phrase both cases as the single mechanism they actually are. Note that the struct comment at compact/loader.go:73-74 and the matching one at hnsw/startup.go:101-102 still describe the discard behavior and contradict the implementation. Tracked separately on the core side.
The card read "Configure HNSW index snapshots for faster recovery and
startup." There is nothing to configure in v1.39, but the page still
serves v1.37 and v1.38 readers who can configure it, so the description
now leads with the outcome instead of the action and reads correctly for
both audiences.
Keeps the imperative benefit-first voice of the neighbouring cards
("Reduce memory usage with...", "Enable the built-in..."), and drops the
restatement of the card title, which the title already supplies.
Blocking items: - Move the v1.39 startup-failure behavior out of the historical note and into the main durability prose. It was the last sentence of a box titled "Behavior before v1.39", which told v1.39 readers to skip the highest-consequence fact in the release. - Split the durability paragraph in three so commit logs and snapshots are not conflated. Commit logs, including compacted ones, self-heal by truncation; snapshots are never truncated or repaired and an unreadable one fails the index load. - Stop calling HNSW compaction output a "segment", which contradicts "the vector index does not use segmentation" earlier on the same page. Vocabulary is now commit log, compacted commit log, snapshot, compactor. - Replace en dashes in the env-var rows with "through", matching the other two files. Also: - Compound title on the feature-note include, per the rq-8bit precedent. - Halve the repeated boilerplate in the five env-var rows and point the historical half at a new stable anchor on the pre-v1.39 section, so readers on earlier versions land on the part that applies to them. - Drop "periodically" from the snapshot lead-in (compaction is driven by the compactor, not a timer) and stop framing a snapshot as conditional. - Retitle both scoping notes to name v1.31 through v1.38 explicitly, since snapshots did not exist before v1.31. - Add a caution to the configuration page covering the fail-to-start behavior, which every deprecated env-var row links to. - Name the configuration file that silently accepts these settings. The recovery advice was verified against the compactor deleting its input files after a successful snapshot write, and the loader filtering covered commit logs, which together confirm no local copy survives.
![orca-security-eu[bot]](https://avatars.githubusercontent.com/in/276244?s=60&v=4){kind=small}
There was a problem hiding this comment.
Orca Security Scan Summary
| Status | Check | Issues by priority | |
|---|---|---|---|
 Passed |
Infrastructure as Code |  0  0  0  0 |
View in Orca |
| Passed |
SAST | 0 0 0 0 |
View in Orca |
| Passed |
Secrets | 0 0 0 0 |
View in Orca |
| Passed |
Vulnerabilities | 0 0 0 0 |
View in Orca |
The 1.38.x compatibility row carried literal "-" placeholders for TypeScript, Go and C#. TypeScript v3.14.0 (published to npm on 2026-07-17) is the first released client with v1.38 support: its CI matrix adds WEAVIATE_138 (1.38.2), it ships the Boost query parameter, and it handles the per-collection asyncEnabled setting that v1.38 removed. Go and C# keep their placeholders: the newest published releases (go-client v5.7.3, Weaviate.Client 1.1.1) still target v1.37, and only unreleased main-branch work adds v1.38 support. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01THnwHPggu8hcxb2BTMLLRB
Weaviate serves gRPC-web under the /v1/grpc-web/ path prefix on the existing REST port, so browsers can reach the gRPC API without a second listener. Enabled by default; toggled at runtime with grpc_web_enabled. No client library speaks gRPC-web yet, so this states that the interface exists without implying a supported client path or a runnable example. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01THnwHPggu8hcxb2BTMLLRB
In Weaviate Cloud the gRPC-web interface is reached through the REST Endpoint URL rather than the gRPC Endpoint URL, because it is served on the REST port. Added to the existing "REST Endpoint vs gRPC Endpoint" admonition on the connect page, which already owns this distinction. The default cluster settings page was considered and rejected: it is a table of setting defaults with no endpoint content. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01THnwHPggu8hcxb2BTMLLRB
grpc_web_enabled has no environment variable. Core only ever seeds it with a default DynamicValue and has no os.LookupEnv branch, unlike DEBUG_ENDPOINTS_ENABLED, so it can be set only as a runtime override. - Add the override to the General table with the environment variable column marked "not applicable" rather than left blank or invented. - Soften the page's blanket claim that every runtime configuration corresponds to an existing environment variable. - State on the gRPC API page that there is no environment variable equivalent, so readers who know the convention stop looking. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01THnwHPggu8hcxb2BTMLLRB
- Use the protocol's own capitalisation, gRPC-Web, in prose. Code-font /v1/grpc-web/, grpc_web_enabled and the #grpc-web anchor are unchanged, so cross-links still resolve. - Say to set the override to false rather than leaving the value implied. - Promote the section to a "## gRPC-Web" sibling so the matched Server-side / Client-side pair is no longer split. - Give the no-environment-variable sentence a subject and attach it to the enablement idea. - Drop the rest/REST collision and the vague antecedent. - Tie the client-library guard to the browser framing so it cannot be misread as contradicting client gRPC support. - Make the cloud sentence second person, matching its admonition. - Avoid a third term for the same concept on the runtime-config page. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01THnwHPggu8hcxb2BTMLLRB
The interface can be turned off in two places, and core spells the key differently in each: grpc.grpcWebEnabled in the static configuration file, grpc_web_enabled as a runtime override. Present them as a short list so the camelCase/snake_case split cannot be skimmed past. Also correct the runtime-config note, which claimed the setting could only be set as a runtime override. That is now false. The separate "no environment variable equivalent" statement stands: a configuration file field is not an environment variable. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01THnwHPggu8hcxb2BTMLLRB
docs(release-notes): fill the TypeScript client cell for the v1.38 row
docs: document the gRPC-Web interface (GA in 1.39)
Review feedback on #475 was that the page reads as too alarmist and documents too much of the pre-v1.39 approach. Since v1.39 leaves nothing to configure, the standalone page no longer earns its own URL: its content moves into the storage concepts page and the per-variable reference stays in the env-vars table, which already carried all five variables in full. - Drop the "snapshots are now required to start" caution in favour of plain prose: checksummed blocks, the write-then-delete ordering, and the commit logs on disk being the delta since the last snapshot. - Correct the failure radius. An unreadable snapshot fails the whole shard, not just one vector index. Lazy-loaded shards leave the node up and error per request; eagerly loaded shards fail node startup, and eager is the default for single-tenant collections. - Note the disk-usage reduction on upgrade, attributed to the snapshot replacing the logs it covers rather than to a new snapshot format -- the V3 format predates v1.39. Scope it to loaded shards after the compactor's first cycles, and keep the headroom caveat, since peak usage still rises while a snapshot is written. - Delete the deprecated-env-var section, keeping the two facts that lived nowhere else: the variables are still recognised but ignored, and the equivalent camelCase fields in a --config-file are accepted silently, with no startup warning. - Collapse the pre-v1.39 configuration detail behind a <details>, with the anchor on the heading above it. Docusaurus's Details component has no hashchange handling, so an anchor inside would strand the five inbound env-var links on a collapsed summary. - Redirect the old path to the concepts anchor; the v1.31 release blog and a live kapa answer both cite it. Also fixes the long-standing broken anchor on the vector-cache env var: APITable row ids are the variable name verbatim, so the link needs upper case.
An audit against the v1.39.0 tag found several statements in this section that the code does not support. Four predate this branch and are live on v1-39/main; three were introduced while reworking it. - The HNSW commit log does not fsync per write. It is buffered, flushed as batches are processed, and synced when a log file is rotated. The same applies to the LSM store WAL, which is written but not synced before a request is acknowledged; scope the ack guarantee accordingly, and say the two logs differ in when they sync rather than when they are written. - Snapshot creation still loads the snapshot it supersedes into memory. Only the commit log delta and the new snapshot are streamed. Drop the claims that no snapshot is held and that the in-memory step is fixed cost -- it grows with the node ID space. - Peak disk usage during snapshot creation is above the steady state, since the previous snapshot, the merge inputs and the new snapshot coexist. Do not tell operators to plan for unchanged headroom. - Only snapshots and compacted commit logs are written atomically. Raw commit logs are appended in place, which is why they self-heal from a torn tail. - Self-healing recovers a torn tail, not arbitrary on-disk damage. - A snapshot is created at startup once enough new commit log data has accumulated, not on any change, and only rotated files count. Align the env-var reference with the same wording. Also restores two things the earlier rework lost: that the periodic conditions are conjunctive with their defaults spelled out, and that these options set through a configuration file are ignored silently, with no startup warning -- the one path where an operator gets no signal at all.
docs: fold HNSW snapshots into concepts/storage for v1.39
Reconciles 111 commits of main into v1-39/main, which had drifted far enough that PR #479 could no longer merge. Only _includes/feature-notes/boost.mdx conflicted textually; the other 12 files GitHub reported auto-merged. All 13 were checked against both parents anyway. boost.mdx is the one place both sides could not be kept: main restyled the Preview caution's title on a line the 1.39 work deletes outright, because Boost is GA in 1.39. Took the 1.39 side.
Documents the user-facing surfaces that weaviate-client 4.23.0 adds for Weaviate 1.39, and corrects several published statements that the 1.38 patch line had already made false. Corrections: - similarity.md said diversity selection was 'Not supported' for hybrid search. That has been false since v1.38.6. Multi-vector remains correctly unsupported. - bm25.md and search-operators.md published exhaustive operator lists that omitted AndCross. - replica-movement.mdx and consistency.md published exhaustive replication-state lists that omitted INTEGRATING (added in v1.38.0). - The MMR feature note still carried a preview label and a multi-node caveat that no longer applies, MMR now being a single coordinator pass. - aws/embeddings.md described 'service' as required while also giving it a default. It is optional; core defaults it to bedrock. - A Bedrock snippet used titan-embed-text-v2:0 without the amazon. prefix. Core dispatches on that prefix, so the collection was created and then failed later at import time. New coverage: - Cross-property AND (and_cross), Python and GraphQL, with the tokenization and analyzer constraint that makes it fail. - Diversity selection on hybrid search, including the pagination contract: offset advances by the query limit, not the page size, and nothing validates it. - list_backups() and the list-side incremental_base_backup_id, which is distinct from the create-side parameter of the same name. - dimensions on text2vec-aws, and a location example for text2vec-google. Version markers cite the release a capability actually became available in, not 1.39: v1.37.3 and v1.38.6 for MMR, v1.38.6 for hybrid diversity, v1.38.8 for and_cross, v1.38.0 for INTEGRATING. The client pin moves to 4.23.0 and the test servers to 1.39.0. 4.23.0 is not on PyPI yet, so uv.lock cannot be regenerated and the Python CI lanes will fail at dependency install until it publishes.
docs: 1.39 Python client surfaces, corrections, and main reconciliation
The module has shipped in core since v1.32.6 and has never been documented. The Python client docstring already links /model-providers/morph/embeddings, so that URL has been a 404 since then. This creates it. The integration is a thin wrapper over the shared OpenAI client, which produces the page's most important caveat: the request header is X-Openai-Api-Key, and the missing-key error names OPENAI_APIKEY, which this integration does not read. It reads MORPH_APIKEY. Both halves were reproduced against a live server. endpoint is a path appended to the base URL, not a full URL. It is absent from the module's config defaults, so it appears in a stored collection definition only when set explicitly. Added in v1.38.2 and backported to v1.36.19 and v1.37.10. Client coverage is uneven and the examples show only what is released: TypeScript has no endpoint at the pinned version, C# has no endpoint, and the Go client has no support at all. C# base URL is omitted because the client emits baseUrl where the server reads baseURL, so the value is silently ignored. Morph labels its Embedding API as legacy and planned for deprecation. The page states that and links their notice.
Creates /model-providers/twelvelabs/embeddings-multimodal, the exact URL the Python client docstring links to, which has been a 404 until now. TwelveLabs is best known for video, but this integration vectorizes text and images only. Verified against a live server: nearVideo and nearAudio do not exist as search arguments, and a videoFields entry is accepted and stored but never read. The pages say so up front, since a reader arriving from TwelveLabs' own material will assume otherwise. Three settings that appear to work and do not: vectorizeClassName is written into every such collection but never read, and per-property skip and vectorizePropertyName have no effect. Property selection is purely textFields and imageFields membership. The integration is not rate limited. It sends one request per text value and one per image, and processes batches of ten in parallel, so a large import can produce a high request rate. A collection naming neither field is accepted by the server and then fails at insert with a misleading error. The page states the requirement as intent rather than claiming the server validates it. Only the typed vectorizer configuration is Python-only. Search and batch import work from every client, so the page says that rather than implying the whole integration is Python-only.
https://docs.morphllm.com/api-reference/endpoint/embedding returns 404. It was cited four times and turned validate-links-dev red. Morph removed the embedding pages from their published docs entirely. Verified against every one of the 91 URLs in their sitemap (all 200): none is an embedding page. /api-reference/endpoint/embedding, /api-reference/endpoint/embeddings, /api-reference/embedding, /models/embedding, /models/embeddings, /embedding, /embeddings and /sdk/components/embedding(s) all 404. The rest of the /api-reference/ tree is alive, so only the embedding pages were pulled. No live Morph page carries the "legacy, planned for deprecation" wording any more, so there is no specific page to repoint the caution at. The wording survives verbatim only in their llms-full.txt dump, which is not a reasonable target for a reader. The caution therefore keeps its prose unlinked and sends the reader to the docs root to check current status, which is what the sentence already asked them to do. The claim is unchanged and still scoped to what Morph's docs say. The Available models reference gets a genuine specific target instead: /api-reference/endpoint/models documents GET /v1/models, which returns the model ids a key can use. That is what the sentence promises. Every URL in the page set now returns 200. The two 401s (api.morphllm.com, the Google Slides note) are inline code and an HTML comment, not rendered links, and the latter is boilerplate on every provider index page. Refs board a9bf4a68: whether the models themselves are retired is still open and is deliberately not asserted here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
docs: add the text2vec-morph model provider page set
docs: add the multi2vec-twelvelabs model provider page set
Document the new generative-deepseek module (DeepSeek as a generative/RAG
provider), available from v1.36.19, v1.37.10, and v1.38.2.
- New provider pages model-providers/deepseek/{index,generative}.md (Python only for now)
- Document the X-Deepseek-Api-Key and X-Deepseek-Baseurl headers and the
DEEPSEEK_APIKEY env var
- Config keys (model, temperature, maxTokens, frequencyPenalty,
presencePenalty, topP, baseURL, stop) with defaults
- Recommend deepseek-v4-flash / deepseek-v4-pro; note deepseek-chat and
deepseek-reasoner are legacy aliases (deprecated 2026-07-24 per DeepSeek)
- Add DeepSeek to the model-providers table and sidebar
- Python snippets show the intended Configure.Generative.deepseek(...) syntax
(client support to follow); kept out of the CI snippet allowlist
The page shipped with a deprecation notice written as a future event (2026-07-24). That date has passed, so state it as settled fact: deepseek-chat and deepseek-reasoner are retired and DeepSeek no longer serves them. Core still ships DefaultDeepSeekModel = "deepseek-chat" (modules/generative-deepseek/config/class_settings.go:33, still true on v1.38.7), so the page's basic no-model example resolved to a retired alias. Present setting `model` as required rather than as an optional refinement: drop the no-model example, lead "Configure collection" with the warning and then the model-setting example, and disclose the built-in default as a caution instead of a neutral fact. Name only the current model names and link DeepSeek's pricing page rather than maintaining a catalogue. Correct "Header parameters", which was wrong. X-Deepseek-Api-Key does not override collection config (there is no API key there); it overrides the DEEPSEEK_APIKEY env var, and with neither set the request fails with "api key: no api key found" (clients/deepseek.go:240-248). X-Deepseek-Baseurl outranks the query-time baseURL param as well as the collection baseURL (clients/deepseek.go:75, 232-238). Also note that the base URL must be an API root, since Weaviate appends /chat/completions to it. Add two traps that were missing. MODULES_CLIENT_TIMEOUT defaults to 50s and covers the whole request including the body read (usecases/config/environment.go:869-876); the module's own acceptance test raises it to 120s, so reasoning models need a note. And the maxTokens ceiling is only consulted for the two retired aliases, so for a current model a value above the model's limit passes validation and only fails later as an error from DeepSeek; negative values are still rejected for every model by the unconditional arm of the same check (class_settings.go:89). Fold the reasoning caveats into one "Reasoning models" subsection rather than stacking admonitions, and link MODULES_CLIENT_TIMEOUT by its APITable row anchor. Update the Python snippet guard comment: Configure.Generative.deepseek() and GenerativeConfig.deepseek() are merged upstream (PR #2084, commit afc0e0eb) and signature-matched, but are not in a released client, so the blocks stay display-only and out of the test allowlist. Ignore platform.deepseek.com in the link validator; it 403s automated requests but loads fine in a browser, matching existing entries.
The DeepSeek blocks shipped behind DEEPSEEK_CLIENT_AVAILABLE = False with a TODO to lift the hold once pyproject.toml pinned a client release containing Configure.Generative.deepseek() and GenerativeConfig.deepseek() (PR #2084, commit afc0e0eb). This base pins weaviate-client==4.23.0, and both builders exist at that tag with the keyword-only signature the snippets already use: base_url, model, temperature, max_tokens, frequency_penalty, presence_penalty, top_p, stop. Per that TODO: set the flag to True, drop the now-empty guard and unindent the three blocks, and switch their FilteredTextBlock language from pyindent back to py, since there is no longer a guard indent to strip. The TODO's fourth clause, adding this file to the allowlist in tests/test_python.py, is deliberately not carried out. No model-provider include is in that allowlist; it lists only files under _includes/code/. Executing this file end to end would run every provider's snippets and require a credential per provider, so these blocks stay display-only like every other block in this file.
Every other model provider directory carries one; deepseek was the only one without. Position 225.5 places it between Databricks (225) and DigitalOcean (226), which matches its row in the provider table and its sidebar position.
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.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
docs: add the generative-deepseek model provider page set
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>
chore+docs: uv.lock for 4.23.0, and_cross sweep, and the v1-39 OpenAPI pin
The search_mode.py snippet passes effort= to QueryAgent.search(), which 1.7.0 does not accept. 1.8.0 adds it. The pin already allowed the newer release; the lockfile was simply resolved before it existed.
The Python lane failed on a bare AssertionError at the geo-range check in _includes/code/howto/manage-data.create.py (CI run 31718384134). The rendered example is correct; the test scaffolding after the WithGeoCoordinates markers was racing the index. A geo property is backed by its own index, and the test instances run with ASYNC_INDEXING enabled, so that index is filled in the background. Measured against local servers with ASYNC_INDEXING=true, the just-inserted object becomes visible to a within_geo_range filter after roughly 0.5 to 1.3 seconds: immediate on 1.38.0, 1.38.3 and 1.38.4, delayed from 1.38.5 onward, including 1.38.7 and 1.39.0. With ASYNC_INDEXING=false it is immediate on every version tested. main pins the test server at 1.38.0 and this branch pins 1.39.0, which is why the race only surfaces here. Add a bounded readiness wait before the assertion, mirroring the pattern already used in _includes/code/howto/search.filters.py, and clear the Publication collection first so the exact count cannot pick up an object left behind by an earlier failed run. The assertion stays exact and the rendered block is unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
java-client 6.3.1 (tag 6.3.1, no v prefix, published 2026-08-13) adds the AND_CROSS BM25 operator, hybrid diversity selection and multi2vec-twelvelabs support. multi2vec-twelvelabs is served by Weaviate 1.39.0 and is absent from 1.38.7, and AND_CROSS needs 1.37.15, 1.38.8 or 1.39.0, so 6.3.1 is the 1.39 client. Link built like the neighbouring 1.38.x cell. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
fix: async geo index race in the create-objects test, agents 1.8.0, and the Java 1.39 compat cell
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.
Release PR aggregating the 1.39 documentation from the
v1-39/mainintegration branch intomain. Weaviate v1.39.0 shipped 2026-08-04.Included
schema_tx_*Prometheus metrics removed frommonitoring.md; Boost promoted from preview to GA, with theBoostPreviewinclude alias renamed toBoostNoteacross the five search pages that render it.PERSISTENCE_HNSW_SNAPSHOT_*env vars are deprecated no-ops. Snapshot content folded intoconcepts/storage.md./v1/grpc-web/, enabled by default, no environment variable equivalent.maininto this branch, which is what makes this PR mergeable again.Each component passed a verifier build individually. This PR's CI is the authoritative combined build.
Not included
weaviate-python-client4.23.0 is released and the client pin moves.maindirectly; it is experimental and not 1.39-gated.Flag for the release owner
#475 documents that in 1.39 an unreadable HNSW snapshot fails index startup where 1.38 self-healed. That behaviour change is tracked as a pre-GA engineering question. Only that one paragraph in
concepts/storage.mdis contingent on it; if the fallback is restored, revert that paragraph.After #508 merges, the Python lanes here will fail at dependency install until
weaviate-client4.23.0 publishes to PyPI. Expected, and it clears itself.