Ospitiamo un server di pacchetti pubblico a disposizione di tutti. Non è necessario configurare nulla. Sia lo strumento Yak CLI che Rhino sanno già dove cercare.
I pacchetti condivisi sul server pubblico dei pacchetti possono essere scaricati e installati liberamente. Possono essere usati in modo gratuito o possono richiedere una licenza: consultare le guide Cloud Zoo e Zoo per i modi di implementare le licenze nel proprio plug-in usando i nostri strumenti.
Di seguito, sono riportate alcune informazioni utili sul nostro server di pacchetti.
Autenticazione e autorizzazione
L’autenticazione, fornita da Rhino Accounts, è necessaria solo per pubblicare pacchetti, non per scaricare/installare.
Una volta che l’autore ha pubblicato un pacchetto, solo lui può pubblicare versioni future utilizzando lo stesso nome del pacchetto.
Convenzioni
Il server dei pacchetti ha alcune convenzioni che devono essere seguite.
Assegnazione nome
I nomi dei pacchetti sono piuttosto rigidi. Sono ammessi solo lettere, numeri, trattini e trattini bassi, ad esempio Hello_World o hello-world1.
I nomi dei pacchetti adottano la distinzione fra maiuscole/minuscole usata nella prima versione caricata. I caricamenti futuri ignorano le maiuscole e le minuscole del nome del pacchetto e tutte le query non sono sensibili a maiuscole/minuscole.
Versioni
I numeri di versione dei pacchetti devono seguire Semantic Versioning 2.0.0 (ad esempio 1.1.0-beta) o System.Version, ovvero lo standard a quattro cifre di Microsoft (ad esempio 1.2.3.4).
Si consiglia di usare il versionamento semantico, perché consente agli autori dei pacchetti di specificare le versioni precedenti al rilascio. Questi sono utili per effettuare test limitati, poiché di default viene installata l’ultima versione stabile.
I numeri di versione a quattro cifre sono stati aggiunti alla versione 0.8 (agosto 2019) per supportare i plug-in esistenti che utilizzano numeri di versione in stile System.Version. Non supportano i metadati di pre-release o di build.
Numeri di versione parziali e normalizzazione
Quando viene creato un pacchetto, notiamo che il numero di versione nel nome del file è diverso da quello in manifest.yml. Ciò è dovuto alla normalizzazione del numero di versione. Questo stesso processo avviene dietro le quinte del server dei pacchetti e serve a evitare ambiguità tra versioni semanticamente equivalenti.
Ci sono due casi in cui i numeri di versione possono essere semanticamente equivalenti.
- Versioni semantiche che differiscono solo nei metadati di compilazione1, cioè
1.0.0+build.1e1.0.0+build.2. - Una versione a quattro cifre e una versione semantica che sono identiche tranne che per la quarta cifra “0” (senza metadati di prerelease o build), ad esempio
1.2.3e1.2.3.0.
La normalizzazione è diversa dall’espansione di numeri di versione parziali (ad esempio 1.0). I numeri delle versioni parziali vengono espansi e memorizzati nella loro forma completa. Ad esempio, se si carica un pacchetto come 1.0, questo verrà effettivamente salvato come 1.0.0. Successivamente, qualsiasi richiesta (REST, CLI, ecc.) per la versione 1.0 sarà automaticamente reindirizzata.
