Release cycle it IT

Ciclo di rilascio

ASF utilizza il versionamento C# comune con 4 numeri, scritto come A.B.C.D. La versione data è sempre congelata, indicando un codice sorgente fisso da cui è stato costruito (raggruppato insieme con il rilascio). Non abbiamo intenzione di rimuovere alcuna versione precedentemente pubblicata, purché il nostro provider di hosting (GitHub) rimanga bene con la conservazione per un futuro indefinito, in modo da poter tranquillamente rollback a qualsiasi di loro senza la necessità di fare auto-copie.

In generale in termini di versione di ASF, stiamo facendo del nostro meglio per seguire il versionamento semver di MAJOR. INOR.PATCH sui 3 numeri meno significativi - B.C.D. Questi tre numeri sono direttamente collegati al codice di ASF. Il numero A più significativo indica cambiamenti con un ambito che va oltre il codice ASF stesso, di solito influisce direttamente sulla fondazione del programma.

ASF come progetto mira ad avere più o meno una release di funzionalità al mese, indicato da un urto del numero C. In order to make such release possible, we have smaller pre-releases dedicated to advanced users, which serve as smaller milestones of changes that are released on as-needed basis when there will be enough of changes since the last pre-release to focus on. Alla fine, quando un pre-rilascio finale sarà determinato per essere stabile e abbastanza maturo con nessuna regressione critica nota che deve essere corretta rispetto al precedente rilascio stabile, sarà promosso alla nuova release stabile, allo stesso tempo aprendo un nuovo ciclo mensile per quello successivo.

Mentre stiamo facendo del nostro meglio per garantire che anche le nostre pre-release siano relativamente stabili, va notato che le preversioni dovrebbero essere attentamente valutate quando si esegue in qualsiasi ambiente di produzione. I pre-rilasci potrebbero avere bugs critici **** e funzioni altrimenti non funzionanti, che è esattamente il motivo per cui li stiamo rilasciando per cominciare - in modo da poter evitare tutto quel pasticcio nelle nostre costruzioni stabili e offrire software affidabile. Se non sei disposto ad accettare un rischio maggiore derivante dall'utilizzo di un software potenzialmente instabile, si prega di evitare di utilizzare le nostre build pre-release e bastone con la nostra build più recente , che è più appropriato per la maggior parte degli utenti.

A seconda della quantità di cambiamenti nel ciclo, di solito ci sarà un singolo bump di versione C (da precedente stabile), e D urti per ogni pre-release su base necessaria. Tuttavia, quando si introducono cambiamenti di portata molto maggiore, in particolare rompendo i cambiamenti, il ciclo potrebbe iniziare da (o passare nel centro a) B o anche A salto - tale interruttore indica che il ciclo di rilascio corrente ha un potenziale di essere più instabile del solito, e dovrebbe essere testato con attenzione. Tieni presente che le modifiche semver che stiamo facendo riguardano solo la versione stabile rilasciata in precedenza, non tracciamo il versionamento tra pre-release in un ciclo stesso, il che significa che la versione 1. .1.2 potrebbe avere una nuova funzionalità che 1.0.1. non ha avuto fintanto che il rilascio stabile precedentemente contrassegnato è dalla famiglia 1.0.0.X. Allo stesso modo, ci potrebbero essere importanti cambiamenti di rottura anche in due pre-release dello stesso ciclo, che è particolarmente vero quando stiamo ancora decidendo circa la forma finale di nuove funzionalità introdotte o simili.

Sbalzo della versione	Semver	Esempio di modifiche
A		I grandi cambiamenti di runtime .NET, cambiamenti di fondazione, cambiamenti di rottura che sono oltre il codebase di ASF, roba che potrebbe mangiare il tuo gatto
B	Maggiore	Cambiamenti di runtime .NET minori, interruzioni delle modifiche del codice ASF, modifiche di codice importanti che vanno oltre la classificazione minore
C	Minore	Nuovi cicli mensili, di solito introducono nuove funzionalità, comandi, proprietà di configurazione o altre modifiche che non interrompono le impostazioni esistenti
D	Patch	Nuove preversioni che fanno parte del ciclo esistente (indicate da un numero più significativo), correzioni critiche di bug a rilasci stabili esistenti che non introducono modifiche di codice oltre il necessario

Si prega di notare che le nuove funzionalità e modifiche introdotte possono essere non documentate (ad es. sulla wiki) fino a qualche tempo dopo, siccome la documentazione è di solito scritta una volta che il codice finale della funzione data è pronto (per risparmiare tempo riscrivere la documentazione ogni volta che decidiamo di modificare la funzione su cui stiamo attualmente lavorando). A causa del fatto che i pre-release possono contenere codice work-in-progress che non ha ancora un modulo finale, la documentazione può arrivare nella fase successiva dello sviluppo. Stessa cosa vale per il changelog generale che può non essere disponibile per il pre-rilascio dato fino a qualche tempo dopo. Pertanto, se decidi di utilizzare le pre-release, sarai preparato per cercare all'interno di ASF commette di tanto in tanto. Naturalmente, la mancanza di documentazione applica solo alle pre-release - ogni versione stabile deve sempre avere un changelog completo e la documentazione sulla wiki nel momento in cui viene rilasciata.

Il changelog preciso che confronta una versione con un'altra è sempre disponibile su GitHub - attraverso commit e modifiche del codice. Nel rilascio tendiamo a documentare solo i cambiamenti che consideriamo importanti tra l'ultima versione stabile e quella corrente. Un cambiamento così breve non è mai completo, quindi se vuoi vedere ogni cambiamento che è accaduto tra una versione e un'altra (come i nostri aggiornamenti sulle dipendenze) - usa confronto GitHub per questo.

Il progetto ASF è alimentato dal nostro processo di integrazione continua . Ogni costruzione dovrebbe essere riproducibile, quindi non dovrebbe essere un problema per afferrare la fonte (inclusa nella release) di una data versione e compilare te stesso ricevendo lo stesso risultato di quello disponibile attraverso i nostri binari precompilati. In genere evitiamo di compilare rilasci noi stessi, fintanto che i sistemi sono operativi, i binari rilasciati provengono direttamente dal nostro processo IC.