Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

[Feature]: Support multiple versions per ID across catalog types

Offen
  • Stimmt etwas nicht?
#4,719 1 Kommentar 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
python
Bereich
backend-api-design, cli, tooling

Rechercherichtung

The issue describes a major feature to support multiple versions per ID across catalog types (extensions, presets, workflows, steps, bundles, integrations). Start by understanding the existing catalog data structures in the codebase, likely in a catalog module. Review the linked issue #4712 for context on the failure. The work requires designing a backwards-compatible version-history representation, updating lookup logic, and modifying CLI commands like search, info, add, install. Separate PRs are required per catalog family, so the first step is to examine one family (e.g., extensions) and propose the new schema. Tests must cover legacy single-version entries and new multi-version lookups.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

triage-can-wait

Summary

Spec Kit catalogs currently resolve an ID to one advertised version. Customer-hosted, install-allowed catalogs should be able to retain multiple approved releases of the same ID and resolve either the advertised current release or an exact historical version. The failure in https://github.com/github/spec-kit/issues/4712 is one consequence: a bundle pins a component version, but after its catalog entry advances, the older release cannot be selected even if the artifact remains available.

Distinguish capability from publishing policy: The bundled community catalogs are discovery-only, current-tip listings. They do not need to publish historical releases, and this change must not turn them into install sources. Existing first-party and customer catalogs that publish only one version must continue to work.

Desired contract and CLI behavior

  • Define a backwards-compatible version-history representation for each catalog family: extensions, presets, workflows, steps, bundles, and integrations. Keep an unambiguous advertised current release and version-specific URLs, hashes, requirements, and other metadata where relevant; reject inconsistent or malformed release records. Existing single-version payloads remain valid.
  • Support current-by-ID and exact-by-ID-and-version lookup while preserving catalog precedence and install policy. If the selected install-allowed source lacks a requested version, fail explicitly; do not silently install current or bypass a higher-priority/discovery-only source. Define how an explicit catalog/source selector interacts with precedence and the currently parsed but unused bundle component source field.
  • Preserve the behavior of unqualified search, info, add, install, and update commands. Expose available versions and exact selection consistently where appropriate (for example, info <id> --versions and catalog-backed add <id> --version <version>). Keep --from as a direct-URL option, not a catalog selector. A bundle-level --version would select a bundle release; it must not override component pins in bundle.yml.
  • Bundle component pins must resolve the requested release from a trusted source. Download the selected release rather than looking up its ID again; validate its URL/redirects and checksum, and verify the downloaded component's ID and version before installation. Online bundle validation must check the exact version, not merely the ID. Report missing historical releases clearly without synthesizing URLs from tags or silently substituting newer versions.
  • Define installed-component conflicts: a project currently has one installed version per component ID. Installing two bundles that require different versions of that ID must not silently count the second pin as satisfied by the first.
  • Integration catalogs should support versioned metadata lookup, but historical integration install --version is out of scope until historical integration implementations have a supported distribution/install contract. Document that distinction.

Delivery requirement: dedicated PRs per area

Do not implement this as one cross-cutting PR. Deliver separate, reviewable PRs for each catalog family—extensions, presets, workflows, steps, bundles, and integrations—plus a separate bundler PR that consumes exact-version component resolution and handles pin/conflict behavior. If shared contracts or catalog utilities are required, introduce them in a dedicated foundation PR first. Each area PR should carry its own focused tests and documentation; land dependent work in a deliberate sequence so existing single-version behavior stays supported throughout.

Acceptance criteria

  • Each catalog family accepts legacy one-version entries and customer-authored multiple-version entries, with tested current and exact lookups and deterministic source precedence.
  • The associated CLI preserves current defaults and clearly distinguishes displayed versions from installable versions; discovery-only community entries cannot be installed through exact-version selection.
  • Catalog-backed historical installs fail explicitly when the requested version or artifact is unavailable, and verify the selected artifact's identity/integrity.
  • Bundles can install their pinned historical component releases from configured install-allowed catalogs and reject incompatible already-installed versions rather than silently skipping them.
  • Regression coverage includes old clients' expected current-version fields, missing/malformed releases, source policy and precedence, and version-specific metadata; reference documentation describes the new format and limits.

Related: https://github.com/github/spec-kit/issues/4712.

Vorherrschende Sprache
Python
Sterne
138k
Forks
12.4k
Ø Merge
2 T. 18 Std.
Gemergte PRs (30 T.)
173

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus github/spec-kit

Alle Issues in github/spec-kit

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.