At this point, it is not possible to build an automated system for updating and managing the various versions through the layer pack manager.

This will be postponed until after the structured databases for the records have been created.

Here is part of the discussion:

Asking:

---

eh no comporterebbe una logica gigantesca ora update. Volendo, possiamo discutere al volo per abbozzare una milestone di prossime versioni ... qui ora abbiamo la versione del pack, la versione online, se ufficiale l'abbiamo su percorsi sommariamente stabili ma la cosa migliore sarebbe usare i records. Quindi scarrellati i records alla ricerca di quei git diventa un caos sapere quale sia l'ultima loro versione e come fare un update dignitoso, cioe' che abbia una prassi definibile tra diverse repository secondo me questa puo' essere fatta solo dopo i DB, dove possiamo aggiungere proprietari e versioni del pack fornito o siamo impossibilitati. Tu, che pensi? che suggerisci?

---

Response:

Sì. La tua lettura è giusta: adesso quella parte non va chiusa bene senza alzare troppo la complessità.

Per il core il versioning è trattabile, perché hai:

• una repo nota
• un path noto
• una policy unica

Per i pack no, perché ti mancano almeno tre cose strutturali:

1. Identità stabile del pack

• il nome da solo non basta sempre
• il repo URL può cambiare
• il record markdown è troppo povero per essere fonte autorevole forte

2. Owner / provenienza

• chi mantiene quel pack?
• è ufficiale, community, privato?
• quale repo è la fonte vera?

3. Version feed coerente

• tag?
• branch?
• manifest version?
• release?
• records?
• quale prevale?

Senza DB o almeno un registry strutturato vero, fare “update dignitoso” per i pack significa inventarsi regole deboli e piene di eccezioni.

Quindi la mia risposta secca

Sì: io la rinvierei dopo il DB.

Perché oggi puoi anche mostrare:

• versione locale
• repo URL
• magari versione ufficiale se il repo è chiaramente noto

Ma fare:

• discovery affidabile
• confronto versioni
• update cross-repo coerente

senza un registro dati serio è troppo fragile.

Quello che farei adesso

Per la V1/V1.1 terrei il viewer dei pack su un livello onesto:

• pack label
• local version
• repo_url se disponibile dal record/manifest
• record source se ufficiale/community
• eventualmente un flag:
  • online version: not available yet

Cioè:

• viewer informativo
• non update manager dei pack

Questa è una posizione molto più solida.

Milestone futura sensata

Quando arrivi al DB, il modello giusto secondo me è:

packs

• id
• label
• owner
• maintainer
• kind (official, community, private)
• source_repo
• source_branch / release_channel
• current_declared_version
• latest_known_version
• status

versions

• pack_id
• version
• source_tag
• published_at
• integrity
• notes

owners / maintainers

• relazione chiara con account/progetti

Con una struttura così:

• il viewer diventa serio
• l’update può avere policy coerenti
• non devi grattare markdown e repo sparse

Quello che sconsiglio

Non fare ora una roba che:

• legge records.md
• prova a risalire al repo
• tenta di dedurre l’ultima tag
• confronta versioni eterogenee
• poi aggiorna “forse”

Perché sembra intelligente ma è una trappola operativa.

In breve

Io suggerisco questo:

Ora

• core version viewer: sì
• pack version viewer: solo informativo minimo
• no auto-update serio dei pack

Dopo DB

• registry vero
• owner/version/source espliciti
• update packs con prassi definibile

Quindi sì: senza DB o registry strutturato, un update dignitoso dei pack è sostanzialmente impossibile da fare bene. Meglio dirlo chiaramente e non vendere una mezza verità.