Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Doc gap: no discoverable notice that CAGRA's C++ build API changed argument types in 26.10

オープン 初心者向け
  • 何か問題がありますか？
#2,673 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
82/100
issue の種類
ドキュメント
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
cpp
領域
documentation

調査の方向性

CHANGELOG.md と cpp/include/cuvs/neighbors/cagra.hpp から始め、文書化されているリリース履歴と、26.10 で導入された型付きの build() および update_dataset() シグネチャを比較します。C++ の呼び出し形式と戻り値の型における破壊的変更を、関連する CAGRA API のコンテキストとともに説明する、見つけやすい changelog の告知を追加します。外部コンシューマーがアップグレード時にその告知を見つけられれば完了です。

索引モデルが issue の本文から書いたものです。

説明

Doc gap

There's no discoverable notice anywhere in the repo — not CHANGELOG.md, not the CAGRA docs — that cuvs::neighbors::cagra::build()/update_dataset() changed their argument and return types in 26.10. The old call shape (build(res, params, raft::device_matrix_view<...>) returning index<T, uint32_t>) no longer compiles; the new one requires a typed dataset view (device_padded_dataset_view, host_standard_dataset_view, etc., see cpp/include/cuvs/neighbors/cagra.hpp) and returns a matching typed index (device_padded_index<T, uint32_t>, ...).

Everything internal to this repo — the 5 examples/cpp/src/cagra_*.cu examples, the C API in c/src/neighbors/cagra.cpp, the fern docs — is already consistent with the new API. So the gap isn't correctness, it's discoverability for anyone building against the headers from outside the repo.

How this cost us

We maintain a fork of facebookresearch/faiss that links directly against published cuVS releases as a C++ dependency. Rebuilding it against a post-26.10 cuVS release failed to compile with no clue from cuVS's own materials about what changed or why. cuVS's own build and full test suite (35/35) passed on both sides of the change, which only confirms cuVS's own call sites match its own current API — it doesn't help an external consumer at all.

We eventually found that NVIDIA's own faiss maintainer had already fixed this exact break in facebookresearch/faiss#5633 (open since 2026-08-26, not yet merged), and cherry-picked the relevant hunks rather than re-deriving the port. The fix existed, upstream, in a sibling project, before we had any way to know we needed one — because nothing in cuVS pointed at it. A one-line changelog entry would have turned an afternoon of investigation into a five-minute search.

Suggestion

At minimum, a CHANGELOG.md entry for releases that change the C++ header API's call shape — the same instinct that already tracks C-ABI breaks in this repo, just extended to the template header API most C++ consumers (faiss included) actually build against.

Separately, and this is a design opinion rather than a doc request: changing argument and return types on an existing function is a breaking change to anyone calling it, whether or not it's covered by the stated ABI policy. The usual way to avoid forcing an unannounced recompile-or-break choice on downstream consumers is to introduce the new call shape under its own name and deprecate the old one for a release or two, rather than changing the existing signature in place. I'm raising it here because it's the direct cause of this particular gap, not to relitigate the whole API — just flagging it as the kind of change that most needs a changelog line if it's going to happen at all.

主要言語
Cuda
スター
854
フォーク
236
平均マージ
3日 5時間
マージ済み PR（30日）
62

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

NVIDIA/cuvs のほかの issue

NVIDIA/cuvs の issue をすべて見る

似ている issue

Documentation の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。