verzování Seederu

[mariehaskovcova]

prosíme o verzování Seederu - viz schůzka, podle dohody s @horakjirinkp

[Fasand]

Myslis tu schuzku zacatkem brezna, na ktere jsem byl i ja, nebo neco aktualnejsiho? Respektive chcete mit "čitelné" verze (e.g. 1.0.3) nebo staci, kdyz bude nejake linearne rostouci cislo? Dal bych tam treba pocet commitů, to mi funguje docela dobre v dalsich projektech pres git rev-list --count HEAD. Aktualni verze by tedy byla 1282, dalsi (podle poctu commitů) treba 1288 atd.

[mariehaskovcova]

jj, myslím tu březnovou schůzku, myslím, že takhle by to bylo ok. Co myslíš @horakjirinkp?

[gehorak]

Souhlasím, výborný nápad. Varianta s počtem commitů je optimalní, lidsky čitelná bezproblémově pro každého. V podstatě jde o to, aby bylo jednoduše rozpoznatelné s jakou verzí se pracuje.

Vyplynulu mi z toho několik otázek, když všechny pominu, dle mého názoru potřebujeme znát ještě alespoň větev. Tak osobně bych byl raději za něco takového:

git rev-parse --abbrev-ref HEAD && git rev-list --count HEAD

[Fasand]

Ok, co takhle misto vetve tam dat zkraceny hash commitu? Treba 7269c2d@1285 pomoci neceho jako git rev-parse --short HEAD && git rev-list --count HEAD. Nebo klidne i s vetvi master.7269c2d@1285 nebo master@7269c2d@1285

[gehorak]

Ta větev je důležitá, když to postavíme z větve produkce, budu mít jiný počet commitů než když to sestavíme z masteru.

Tady je to již jedno, nejlépe tuto variantu: branch@commit-short@commit-count. Tato varianta nese asi nejpřesnější identifikaci.

[Fasand]

Takhle by se to mohlo zobrazovat v Seederu v navbaru. V pohode nebo to rusi/je nejasne?

[gehorak]

Pokud se nepletu, navbar žadné další využití zatím nemá, za mě, vyhovuje. Případně se domnívám pokud to bude opticky někoho dráždit, nebude zásadní problém to barevně upozadit, nebo přesunout řetězec jinam.

Aktuálně si myslím že to hodně pomůže v orientaci při testování.

Díky, za mě s tím souhlasím.

[JanMeritus]

@Fasand ahoj, pozeram ze sa to uz uzavrelo. Pocet commitu je zatim dobry, nicmene bolo by fajn potom si pripravit nieco na styl verze.majorpodverze.minorpodverze a prevazat to s pull requesty / milniky

[Fasand]

To jsem prave puvodne myslel a nejsem uplne proti a vesmes by to mohlo nahradit to gitove verzovani. Na klasickem manualnim verzovani se mi nelibi ze vim, ze na to drive spis nez pozdeji zapomenu a potom je v tom binec, ale taky mi prijde 1.1.12 citelnejsi a jasnejsi nez 0bfaabd@1319.

Napada me to dat dohromady: verzovat jenom jako verze.majorpodverze a minorpodverze dopocitat z committu, jenom jeste nevim, jak to bude nejjednodussi. Treba bych mohl u kazde major verze (treba 1.2) zadat pocet commitu pred ni a potom by se minorpodverze spocitala jako pocet commitu - pocet commitu pred major verzi.

Ale jsem otevreny napadum. Pokud by byla dulezita jenom nejaka major verze u PR apod, tak klidne muzeme resit jenom X.X verzovani a k tomu paralelne pouzivat tu git verzi pro presnost. S cimkoliv presnejsim a manualnim ale upozornuji, ze bude spousta "update version to 1.X" commitu 😄

[horakjirinkp]

Tak rozhodně je to opticky přívětivější. :)

Nicméně na cestu manuálního verzování bych se vůbec nevydával, je to jistý prostor pro chybu.

Vzniká otázka zda nezačít využívat tagy ( tvaří se jako verze, ale verze to není)
( commit -> tag -> release ), tak nevím.

O verzování se musí také někdo navíc starat.

Mé chápání je takové, že verze verze.major.minor není jenom číslovaní změn v kódu, ale měl by to být nějaký milník z pohledu funkcionality a použitelnosti.

Myslím že pro naše potřeby je aktuální stav dostačující, musíme jenom vědět a rozlišit kde a na jaké revizi pracujeme a testujeme.

Až se vývoj ustálý nebál bych se otázku znovu otevřít.

[Fasand]

@mariehaskovcova uz mi psala, ze to budete resit po vikendu, kazdopadne souhlasim s tebou @horakjirinkp, nejake priblizne verze by se mi taky docela libily jak z hlediska historie tak planovani dalsich issues.

Ty milestones, co jsou ted nastavene, bych v par pripadech urcite upravil, ale rozumim, ze to je zatim nástřel. Takhle bych je ale presne pouzil, jak jsou v podstate ted:

1. Vytvori se treba 3 milestones 1.0.1, 1.0.2, 1.0.3
2. Projdou se existujici issues a po nejake dohode se jim nastavi smysluplny milestone, tedy se to bude planovat treba na ty 3 (nebo jine cislo) minor verze dopredu
3. Ja na tech issues budu podle teto prirazene priority pracovat a jakmile vsechny issues v 1.0.1 dokoncim, tak vytvorim PR s nazvem treba "1.0.1 Takove a makove zmeny"
4. Pokud ve vyvoji zjistim, ze nejaky ten issue v 1.0.1 uplne nehori nebo cekam na vyjadreni ostatnich, tak ho prehodim do 1.0.2 a pokracuji

V kodu by potom ta verze vlastne nemusela vubec byt, protoze tam bude aspon ta orientacni podle poctu commitu, ale klidne i byt a zobrazovat se muze. Ve vysledku pro me bude daleko jednodussi nezapomenout tam hodit ten maly commit "version 1.0.1" jednou za PR nez jednou za par nesouvisejicich commitu.

Kdyz se potom podivas do historie PRs, uvidis jake zmeny se v kazdem updatu delaly a to by melo jeste mozna prehledneji videt i primo v uzavrenych milestones. Pripadne predpokladam, ze nebude problem z jakehokoliv milestone udelat na Githubu release a tim ty updaty "zviditelnit" na jednom jasnem miste.

Kazdopadne proberte to, takhle mi to jenom docela dava smysl.

[mariehaskovcova]

stávající milestony jsou cvičný nástřel, po víkendu se zamyslíme nad prioritami a zkusíme naplánovat, díky

[Fasand]

Milestony a provozni verzovani pres branch@commit-short@commit-count mi aktualne prijde jako dobre reseni a dale bych to asi moc neresil, jelikoz manualni reseni, jak rikal @horakjirinkp, drive nebo pozdeji urcite selze. Verze major.minor by tedy byla zalozena na urovni funkcionality a byla by pouze v milestonech/releasech, nezobrazovala by se v Seederu a tam by se zobrazovala pouze zminena provozni verze.

Muzeme tedy issue uzavrit nebo vas napadlo lepsi reseni?

[mariehaskovcova]

ok, já k tomu už nic nemám, můžeme uzavřít