Release cycle ro RO

Ciclu de lansare

ASF modul de versionare C# cu 4 numere, scrise ca A.B.C.D. Versiunea dată este întotdeauna îngheţată, indicând către un cod sursă fix din care a fost construit (salvat împreună cu pachetele). Nu intenţionăm să eliminăm nicio versiune publicată anterior, atâta timp cât furnizorul nostru de găzduire (GitHub) rămâne în regulă cu păstrarea lor pentru un viitor nedefinit, astfel încât să poți reveni în siguranță la oricare dintre ele fără a fi nevoie să faci autocopii.

În general, în ceea ce privește versiunea ASF, facem tot posibilul să urmăm versionarea de MAJOR.MINOR.PATCH pe ultimele 3 numere cel mai puţin semnificative - B.C.D. Aceste trei numere sunt direct legate de codul ASF. Cel mai semnificativ număr A indică modificări cu un domeniu care depășește cadrul codului de bază ASF în sine, de obicei afectează în mod direct fundația programului.

ASF ca proiect vizează să aibă mai mult sau mai puțin o lansare a unei funcționalități pe lună, indicat de incrementarea numărului 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. În final, în cazul în care se stabilește că eliberarea prealabilă finală este stabilă și suficient de matură, fără regrese critice cunoscute, care ar trebui corectate în comparație cu precedenta eliberare stabilă; va fi promovat la noua lansare stabilă, deschizând în același timp un nou ciclu lunar pentru următoarea versiune.

În timp ce facem tot posibilul pentru a ne asigura că până și pre-versiunile noastre sunt relativ stabile, ar trebui remarcat faptul că pre-diseminările ar trebui evaluate cu atenție atunci când rulează în orice mediu de producție. Pre-eliberările ar putea avea bug-uri critice și alte funcționalități distruse, acesta este exact motivul pentru care le lansăm pentru început - astfel încât să putem evita toate acele disfuncționalități în construcțiile noastre stabile și să oferim software de încredere. Dacă nu sunteți dispus să acceptați un risc crescut care rezultă din utilizarea unui software potențial instabil, Vă rugăm să evitați să utilizați versiunile de pre-autorizare și să rămâneți cu cel mai recent stabil în schimb, care este mai potrivit pentru majoritatea utilizatorilor.

În funcție de numărul de modificări în ciclu, de obicei va exista un singur barem de versiune C (de la starea anterioară), şi D umflături pentru fiecare pre-eliberare la nevoie. Cu toate acestea, atunci când se introduc modificări cu un domeniu de aplicare mult mai larg, în special schimbări revoluţionare; ciclul ar putea porni de la (sau schimba de la mijloc la) B sau chiar A bump - astfel de schimbare indică faptul că ciclul curent de eliberare are un potențial de a fi mai instabil decât de obicei, şi trebuie testate cu atenţie. Țineți cont de schimbările semiale pe care le facem legate doar de versiunea stabilă lansată anterior, nu urmărim versionarea prin pre-lansări într-un ciclu, ceea ce înseamnă versiunea 1. .1.2 ar putea avea o caracteristică nouă care să 1.0.1. nu a avut atâta timp cât versiunea stabilă marcată anterior este de la clasa 1.0.X. În mod similar, ar putea exista schimbări majore de rupere, chiar și în cazul a două pre-eliberări din același ciclu; ceea ce este adevărat mai ales când încă mai decidem asupra formei finale a funcţionalităţii nou introduse sau similare.

Bară versiune	Semver	Exemplu de modificări
A		Schimbări majore ale platformei NET, schimbări ale fundației, schimbări care depășesc codebaza ASF, lucruri care v-ar putea mânca pisica
p	Majore	Comenzi minore .NET, modificări de rupere a codebazei ASF, editare de cod major care depășesc clasificarea minoră
C	Minore	Cicluri lunare noi, introducând de obicei noi funcționalități, comenzi, proprietăți de configurare sau alte modificări care nu întrerup configurările existente
D	Pastă	noi prediseminări care fac parte din ciclul existent (indicate de un număr mai semnificativ), bugfix critic la versiunile stabile existente care nu introduc modificări de cod dincolo de cele necesare

Vă rugăm să reţineţi că noile caracteristici şi modificări introduse pot fi nedocumentate (ex. pe wiki) până cândva mai târziu, pentru că documentaţia este de obicei scrisă odată ce codul final al caracteristicilor date este gata (pentru a economisi timp de rescriere documentaţie de fiecare dată când decidem să modificăm caracteristica la care lucrăm). Datorită faptului că pre-diseminările pot conține cod work-in-progress care nu are un formular final încă, documentaţia ar putea ajunge mai târziu în stadiul de dezvoltare. Același lucru se aplică jurnalului de modificări generale, care ar putea să nu fie disponibil pentru o dată pre-lansare până ceva mai târziu. Prin urmare, dacă decizi să folosești pre-releases, atunci fii pregătit să cauți în interiorul ASF comite din când în când. Bineînțeles, lipsa documentației se aplică numai la pre-lansări - fiecare versiune stabilă trebuie să aibă întotdeauna un jurnal complet de modificări și documentație pe wiki în momentul în care este lansat.

Changelog precis care compară o versiune cu alta este întotdeauna disponibil pe GitHub - prin comitete și modificări de cod. În versiune avem tendința de a documenta doar modificările pe care le considerăm importante între ultima versiune stabilă și cea actuală. O astfel de modificare scurtă nu este niciodată completă. deci dacă doriţi să vedeţi orice schimbare care s-a întâmplat între o versiune şi alta (cum ar fi dependenţele noastre actualizează) - utilizaţi Comparaţie GitHub pentru asta.

Proiectul ASF este alimentat de procesul de integrare continuă. Fiecare construcție ar trebui să fie reproductibilă, astfel încât să nu fie o problemă de a prelua sursa (inclusă în versiune) unei anumite versiuni și de a vă compila primind același rezultat ca cel disponibil prin intermediul binarelor noastre precompilate. De obicei evităm compilarea ne eliberează, atâta timp cât sistemele sunt funcţionale, binarele eliberate provin direct din procesul nostru de CI.