GitHub, come un qualsiasi altro strumento che permette di gestire codice sorgente tramite git, mantiene una history di tutti i rilasci che sono stati fatti, sia come tag che come release. Di fatto non è detto che per un tag ci sia per forza una release corrispondente (es. per le versioni alpha/beta), ma è vero il contrario, cioè che per ogni release creata ci possono essere degli asset (es. un eseguibile, delle release note, etc.) ed è obbligatorio associare un tag.

Se volessimo scoprire quali release sono state fatte nel repository, allora dovremmo lanciare questa query tramite la CLI di GitHub:

gh release list --repo dotnet/runtime

Tuttavia, questa query non tiene in considerazione che anche le release possono essere delle preview e, pertanto, possiamo scartarle per recuperare le ultime stable:

gh release list --exclude-drafts --exclude-pre-releases --repo dotnet/runtime

Ma, di fatto, a noi potrebbero interessare solamente i tag associati:

gh release list --exclude-drafts --exclude-pre-releases --repo dotnet/runtime --json tagName --jq ".[].tagName"

Se volessimo considerare anche l'ordinamento, dobbiamo tenere presente che è già implicito un ordinamento decrescente per data di creazione. Tuttavia dobbiamo prestare attenzione se vogliamo recuperare proprio l'ultima versione: infatti, una hotfix su una versione 1 (es. 1.0.1) potrebbe essere eseguito solo dopo che una versione 2 (es. 2.0.0) è stata rilasciata. Sebbene l'ordinamento temporale potrebbe essere sufficiente, in altri casi ci interessa recuperare proprio l'ultima versione:

gh release list --exclude-drafts --exclude-pre-releases --repo dotnet/runtime --json tagName,isLatest --limit 100 | jq -r '.[] | select(.isLatest == true) | .tagName'

Ciascun elemento release è associato, infatti, ad una proprità isLatest che lo identifica come ultimo. Per recuperarlo, però, dobbiamo assicurarci di ritornare una lista sufficientemente grande di elementi, altrimenti rischiamo che non sia visibile e ottenere null.