Perché i repository più diffusi utilizzano la versione di rilascio come "Titolo di rilascio" in GitHub?

Come gestire la versione con Git e GitHub?

Il modo standard Git di identificare una versione è creare un tag versione . Questo tag indica una versione specifica del tuo software nella cronologia delle modifiche del tuo repository. La maggior parte dei team lavora con i tag, poiché questi sono direttamente disponibili nel repository e possono essere utilizzati nei comandi git.

Le versioni sono una funzionalità GitHub per il software di packaging da consegnare. Ciò consente di aggiungere alcuni file binari scaricabili associati alla versione. Quindi, in termini pratici, la versione include alcuni contenuti web correlati a una versione taggata; non è qualcosa di noto nel tuo repository locale.

Per creare una versione su GitHub, devi inserire un nuovo identificatore di tag obbligatorio (che verrà creato per identificare la versione) e un nome di versione opzionale.

Convenzioni sui nomi

Poiché i tag sono l'identificazione principale di un rilascio, vengono gestiti con attenzione. Di solito segue la convenzione versioning semantico (o qualche variante).

Per il nome, non esiste una convenzione universale. Ma se è vuoto, GitHub prenderà semplicemente il tag di versione che hai appena creato. Questo è il motivo per cui così tanti progetti riutilizzano l'id del tag per il nome della release: non è una scelta deliberata; non hanno nemmeno bisogno di fare un copia-incolla; è solo che non avevano alcun desiderio / tempo / interesse nell'usare una descrizione più creativa e che GitHub lo definisse di default!

Ovviamente puoi usare una convenzione diversa. Potresti utilizzare perfettamente un nome in codice (ad esempio " Longhorn SP2 " invece di "v6.0.6002" come Microsoft sta facendo per Windows oppure " Sandwich gelato " anziché "v4.0.4" come Google sta facendo per Android). Mantenere un tale standard di denominazione a lungo termine richiede un sacco di persone creative se si desidera mantenere i nomi univoci. Più realistico è un approccio misto: usa il tag di versione predefinito per le versioni minori, ma identifica un nome in codice per le versioni importanti (specialmente se queste sono significative per il marketing)

Potresti anche pensare di identificare le nuove funzionalità principali. Tuttavia questo è di uso molto limitato. Innanzitutto, se sei esperto nel separare le versioni correttive e le versioni funzionali (come proposto dalle linee guida per la gestione delle versioni della versione di ITSM), potresti avere qualche problema a trovare un nome significativo per metà delle tue versioni. Quindi, questo schema funziona solo con un piccolo software: se si dispone di un software di livello enterprise, le funzioni principali sarebbero troppo difficili da riassumere nel paio di parole che rimangono visibili nella pagina di rilascio di GitHub. Questo tipo di informazioni è meglio inserire una nota di rilascio.

Questo è uno screenshot più grande della pagina che hai trovato.

NotachediceDocker/Toolboxnell'angoloinaltoasinistradellapagina,quindisaigiàdicosatrattaquestapagina.

Iltitolodellapaginaèv17.04.0.ce-rc1,perchéquestaèlaversionediDocker/Toolboxchevienerilasciata.IlettoripiùespertiriconoscerannochesitrattadiunCandidatodirilascio,comeevidenziatodall'indicatore"Pre-release" e da rc1 come parte del numero di versione.

In breve, se guardi l'intera pagina (invece del solo titolo ottuso), ha senso.

Vorrei anche notare che è stato abbastanza semplice trovarlo in Google, semplicemente cercando il numero di rilascio che mi hai dato.