Feature: Multiple Models Per Version

[mkaic]

Code and PR description are LLM-generated.

MMPV support: first-class Training / TrainedModel + backwards-compat

Adds DNA-style multi-model-per-version support to the SDK, consuming the new v2
external trainings endpoints.

Companion PRs:

• roboflow-mcp #79 feature/mmpv → main (MCP client)
• roboflow-python #497 feature/mmpv → main (SDK client)

What this adds

• roboflow/core/training.py — new Training and TrainedModel objects.
  A version owns many trainings; a training owns one or more models (NAS owns
  many). TrainedModel.predict() infers by <ws>/<model-slug>;
  .download() pulls weights by model id.
• adapters/rfapi.py — v2 trainings adapter
  (list_trainings_for_version, get_training, create/cancel/stop_training_v2,
  get_model_weights_url) mirroring the MCP's rf_api.py 1:1. The
  legacy-vs-MMPV branch lives on the backend, never in the client.
• Version gains .trainings(), .models(), and a back-compat .model
  property that resolves the sole model and refuses to guess when a version
  owns several — raising with a CTA to version.models().

Backwards compatibility

Old installs keep hitting the frozen v1 routes, which the backend now makes
MMPV-aware. Single-model MMPV versions still work for metadata, train()
poll-reads, and weights download; only predict() on MMPV is the deliberate
casualty (requires the new <ws>/<model-slug> id).

Tests

tested e2e with both new and old versions of package and verified expected behavior/graceful-degradation on both legacy and MMPV versions on staging.

[jarbas-roboflow]

Status: ❌ Request Changes — Gist: https://gist.github.com/jarbasrf/3c6059e57956669c2be838307254f445. Resumo: The PR changes Version.model into a raising network-backed resolver and exposes MMPV models through object-detection-only inference behavior, which risks public SDK regressions and incorrect predictions.

[jarbas-roboflow]

Status: ❌ Request Changes — Gist: https://gist.github.com/jarbasrf/fbfdc78d9c9c21ed3ef62cf90bd30955. Resumo: The artifact was written to the requested path. The main remaining issue is that Training.models can drop training-level modelType, causing non-detection MMPV models to fall back to object-detection routing under the documented response shape.

[jarbas-roboflow]

Status: ✅ Approve — Gist: https://gist.github.com/jarbasrf/f53f7a4dedd198da2b3b86edf18fabea. Resumo: The previously reported Training.models training-level modelType propagation issue is resolved at current head, with focused regression coverage. No new merge-blocking issue was found.

[jarbas-roboflow]

Status: ❌ Request Changes — Gist: https://gist.github.com/jarbasrf/e547be780a0c8fbda40ed65805fc6ad0. Resumo: The prior MMPV issues remain resolved, but current head adds a core Version construction regression via an extra uncaught network request, plus a missing MkDocs Trainings page.

[jarbas-roboflow]

Status: ✅ Approve — Gist: https://gist.github.com/jarbasrf/25192f4b64448ea98d5b32b989275840. Resumo: The prior Version constructor network regression and missing MkDocs Trainings page are fixed at current PR head. No remaining concrete correctness issue found in the reviewed diff.