Release proces pro bk_client a add-ony

[agajdosi]

Na dnešní schůzce jsme se dohodli že, víceméně pojedem CICD:

1. bk_client se bude buildit a releasovat na každém commitu do main branche.
2. verze bk_client bude na konci doplněná o hash (v1.13.0-abcdefgh), abysme mohli lehčeji řešit problém, že někde někomu zůstane verze 1.13.3 z testovani PR a pritom finalni 1.13.3 bude jina, hashem to pripadne muzeme easy overit, pohodlnejsi nez sha256sum.
3. add-ony definují verzi bk_client, kterou očekávají (ideálně může být minor nebo i patch), relase add-onu, v CI (vyjimecne manual) nebude buildit bk_client, ale stahne si ocekavanou verzi z bk_client releasu na GH. Diky definovani ocekavane verze muze alpha, beta, rc add-onu mit stabilni verzi clienta, zatimco vyvoj na clientovi muze vesele bezet dal.
4. add-ony pro lokalni vyvoj umoznuji i build bk_client primo na dev stroji, add-on repo v tomto pripade idealne prejima build z dev.py v bk_client repu. Je to jen zkratka, jak rychleji implementovat zmeny na clientovi ve spojeni s novou feature v add-onu. Jakmile je hotovo, je potreba udelat PR na bk_client, otestovat, ze to nerozbiji dalsi add-ony, jakmile je mergnute, idealne mergovat zmeny na add-onu.
5. PRs na bk_client by měly trignout testy z repozitaru add-onu, je treba vymyslet, jak to spoustet a jak jim deliverovat zrovna zbuildenou verzi bk_client, respektive jak jim automaticky nastavit ocekavanou verzi oproti jejich vuli.

Pokud jsem něco zapomněl, tak mě prosím doplňte nebo opravte @vilemduha @Tweekazoid
FYI ping @yac

[Tweekazoid]

za me ta hash je asi dobry napad. ale propsal bych to jen do nejakych metad.

Ted aktualne kazde PR incrementuje patch verzi automaticky, takze by se nikdy nemelo stat ze se do releasu dostane jedna verze 2x
Proto prave se ani nespecifikuje patch verze v addonu.