5.3 Ciclul de eliberare post-mortem

Dupa cifre

Acest ciclu a fost mai lung, durand putin peste sase luni. Etapa de dezvoltare (alfa) a fost de 138 de zile, de la 8 mai pana la 23 septembrie. In acest timp, au existat 779 de confirmari la 5.3 (directorul trunk A in Subversion care contine cel mai recent cod de dezvoltare in pregatire pentru urmatorul ciclu de lansare major. Daca rulati „portbagaj”, atunci sunteti la ultima versiune.). Cei mai activi comiteri au fost @SergeyBiryukov cu 426 (fara surprize acolo), @pento 66, @afercia si @desrosj cu 51 de comitere fiecare.

„Beta O pre-lansare a software-ului care este oferit unui grup mare de utilizatori pentru a fi testat in conditii reale. Versiunile beta au trecut prin testarea alfa in interior si sunt, in general, destul de apropiate in ceea ce priveste aspectul, senzatia si functionarea produsului final; cu toate acestea, modificarile de proiectare apar adesea ca parte a procesului. ” etapa a inceput pe 23 septembrie si a durat 23 de zile. Au fost 274 de comiteri. Cei mai activi comiteri au fost @SergeyBiryukov cu 78, @afercia 42, @desrosj 34 si @whyisjake cu 24 de comitere.

„Candidatul de lansare Una dintre etapele finale ale ciclului de lansare a versiunii, aceasta versiune semnaleaza potentialul de a fi o lansare finala pentru public. A se vedea si alfa (beta). ” etapa a inceput pe 16 octombrie si a durat 27 de zile. Au fost 100 de confirmari, inclusiv documentatie si modificari ale instrumentelor de construire. Cei mai activi au fost @SergeyBiryukov cu 39, @desrosj 20 si @johnbillion cu 14 comits. Au existat 30 de confirmari care au fost imbinate cu directorul 5.3 ramura A din Subversion. WordPress foloseste sucursale pentru a stoca cel mai recent cod de dezvoltare pentru fiecare versiune majora (3.9, 4.0 etc.). Sucursalele sunt apoi actualizate cu cod pentru orice versiuni minore ale acelei sucursale. Uneori, o versiune majora a WordPress si versiunile sale minore sunt denumite in mod colectiv „ramura”, cum ar fi „ramura 4.0”. dupa ce a fost creata pe 29 octombrie.

In total, ciclul de lansare a durat 188 de zile si au existat 1.153 de confirmari. Privind cifrele, cel mai aglomerat moment a fost in timpul beta, cu o medie de aproape 12 comiteri pe zi. Pentru comparatie, au existat doar aproximativ 5,5 angajari pe zi in etapa „alfa” *.

Imbunatatiri necesare

Au existat si unele nereguli in timpul ciclului 5.3.

• Multe „noi” remedieri de erori au fost comise in timpul beta. In general, acestea sunt adaugate in alfa, iar beta este rezervat pentru testarea si remedierea oricaror erori introduse in alfa.
• Au fost comise mai multe imbunatatiri aparente din biletele de corectie partial legate de bug-uri: # 34904, # 47477, # 47153 etc.  De preferinta, ar exista o relatie discreta 1: 1 intre bilete si seturi de modificari.
• Unele coduri care ar fi considerate „alfa” (majoritatea netestate si nerecomandate) au fost comise in timpul versiunii beta. De preferinta, orice cod angajat in versiunea beta este bine revizuit de mai multi oameni cu cunostinte / experienta variate cu codul existent / domeniile de expertiza.

O abatere substantiala fata de versiunile anterioare a fost includerea foilor de calcul CSS „globale” in cascada. modificari care afecteaza toti administratorii WordPress (si super admin) in timpul versiunii beta. Au fost comise din bilete fara legatura sau partial corelate: [46241], [46360], [46244] si majoritatea celorlalte seturi de modificari marcate ca „Imbunatatiti si modernizati controalele interfetei utilizator”.

Ar fi fost de preferat ca modificarile sa fie separate in bilete noi, testate, revizuite si apoi comise. Separarea acestora in bilete individuale ar fi permis, de asemenea, imbunatatirile sa fie izolate si pregatite pentru urmatoarea versiune majora A, identificata prin primele doua numere (3.6), care este punctul central al unui ciclu complet de lansare si a dezvoltarii caracteristicilor. WordPress foloseste numarul zecimal pentru versiunile majore de lansare, astfel incat 2.8, 2.9, 3.0 si 3.1 sunt secventiale si sunt comparabile ca domeniu.

In mod individual, niciuna dintre neregulile enumerate mai sus nu reprezinta o mare problema, dar, luata impreuna, a introdus o complexitate evitabila. In acest caz special, au fost introduse multe bug-uri mici de stil in timpul versiunii beta, care este mult prea tarziu in ciclul de lansare. Din nou, individual, au fost rezolvabile, dar introducerea lor tarzie si lipsa de bilete discrete au lasat oamenii fara suficient timp pentru a le gasi si a le remedia pe toate.

Inainta

Exista cativa pasi care pot fi luati pentru a evita astfel de nereguli in viitor:

• Adaugati cateva „Release Cycle 101” la documentatia dezvoltatorului. Acest lucru va asigura ca persoanele fara experienta anterioara se afla pe aceeasi pagina. In general, in timpul alfa totul merge. Trunchiul poate fi rupt si reparat in fiecare zi, deoarece contribuitorii repeta imbunatatirile si remedierile de erori. Beta este pentru testare de catre utilizatori si pentru a remedia erorile care au fost introduse in alfa. RC este „credem ca este gata, gasiti cazurile de margine!” 
• Adaugati o cerinta pentru o revizuire a codului pentru toate modificarile efectuate in timpul versiunii beta. In general, acest lucru a fost cazul pentru majoritatea comitetelor atat in ​​timpul alfa, cat si beta. Necesitatea unei revizuiri inainte de fuziune functioneaza foarte bine in Gutenberg Proiectul Gutenberg este noua interfata de editor pentru WordPress. Editorul imbunatateste procesul si experienta de a crea continut nou, simplificand mult scrierea continutului bogat. Foloseste „blocuri” pentru a adauga bogatie mai degraba decat coduri scurte, HTML personalizat etc. https://wordpress.org/gutenberg/. Este timpul sa-l „oficializam” pe Trac Un proiect open source de Edgewall Software care serveste ca instrument de urmarire a erorilor si instrument de gestionare a proiectelor pentru WordPress. de asemenea.
• Eliminati partea „(binecuvantat)” din biletul „task” Creat atat pentru rapoarte de erori, cat si pentru dezvoltarea caracteristicilor de pe urmaritorul de erori. tastati pe Trac. Se pare ca da impresia gresita ca un bilet poate fi „binecuvantat” de oricine pentru a-i permite sa ocoleasca regulile ciclului de lansare.
• Limitati utilizarea tipului de bilet „task” pe Trac numai la conducerea proiectului. Ocolirea regulilor ciclului de eliberare (propriile noastre) nu este ceva ce poate fi facut usor si poarta o multime de responsabilitati. De asemenea, poate adaugati o cerinta pentru cel putin doua recenzii pentru fiecare modificare / cod in acest caz.
• Poate extindeti sectiunea despre crearea si utilizarea biletelor Trac pentru a interzice in mod specific modificarile care nu au legatura sau partial legate. Acest lucru poate fi oarecum greu de determinat, dar daca aveti dubii, este mai bine sa creati un bilet nou in loc sa extindeti exponential un bilet existent. In 5.3 exista mai multe exemple de astfel de bilete de „fuga”: # 47477, # 47153, # 34904 etc.

* Ritmul de comitere mai lent in timpul alfa se datoreaza partial dezvoltarii de noi caracteristici si nu este angajat pana cand nu este considerat „gata”. Un alt motiv este probabil faptul ca imbunatatirile complexe si eroarea O eroare este o eroare sau un rezultat neasteptat. Imbunatatirile de performanta, optimizarea codului si sunt considerate imbunatatiri, nu defecte. Dupa inghetarea caracteristicilor, sunt tratate numai erorile, regresiunile (modificarile adverse fata de versiunea anterioara) fiind cea mai mare prioritate. remedierile necesita mai multe cercetari, recenzii si teste inainte de a comite. Un alt motiv este ca, probabil, majoritatea contribuabililor se concentreaza mai mult pe noile caracteristici, imbunatatiri si remedieri mai complexe de erori, lasand erorile „usoare” pentru mai tarziu.

# 5-3, # retrospectiva