chroma-core/chroma

[ENH] Client / Server versioning compatibility

Ouverte

#2 524 ouverte le 16 juil. 2024

Voir sur GitHub
 (4 commentaires) (0 réaction) (0 personne assignée)Rust (2 247 forks)batch import
by-chromadeploymentgood first issue

Métriques du dépôt

Stars
 (27 958 étoiles)
Métriques de merge PR
 (Merge moyen 1j 16h) (80 PRs mergées en 30 j)

Description

It's possible for users to not keep upgrades of clients and servers for Chroma in sync (e.g. https://github.com/chroma-core/chroma/issues/2510)

This can lead to confusing errors. In general, we don't want to support mismatched client and server versions, though we do have limited backward compatibility between older client versions (which may be distributed to user machines and might not receive upgrades) and newer servers.

We should:

  • Add a way for clients and servers to communicate their versions to each other
  • Add logic to check for version compatibility
  • Throw friendly error messages explaining the upgrade path, including any commands or utilities which need to be run.

Guide contributeur

Direction de recherche
Examiner le protocole de communication existant entre le client et le serveur (probablement HTTP ou gRPC) pour déterminer où les informations de version peuvent être ajoutées. Examiner la configuration actuelle de gestion de version (par exemple, Cargo.toml pour le serveur, package.json ou setup.py pour le client). Vérifier l'issue de référence #2510 pour les scénarios d'erreur courants. Envisager de mettre en œuvre des vérifications de version dans l'initialisation du client ou le traitement des requêtes du serveur, et définir une politique de compatibilité (par exemple, une incompatibilité de version majeure doit générer une erreur, une incompatibilité de version mineure/patch doit générer un avertissement). Rédiger des messages d'erreur clairs avec des instructions de mise à niveau.
Stack technique
rust
Domaine
backendapi
Type d'issue
Fonctionnalité
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-2 jours
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
RustHTTP/gRPCVersioning concepts
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
45