<i>Když máte v jedné dll opravu chyby i novou vlastnost, nemůžete distribuovat zvlášť záplatu s opravou chyby a zvlášť záplatu s novou vlastností.</i>
Děláme to běžně. Zákazník má opravu k dispozici hned v den, kdy se najde řešení chyby. V dalším release je zahrnutá automaticky, pokud (snadno dohledatelný) vývojář dodrží proces.
Hint: Jiná větev pro release a jiná pro vývoj a možnost vyrobit ze změn path, který se aplikuje na obě větve. Konflikty se řeší tak, že pro každou změnu je extra branch, merge až po dokončení a kdo dělá merge jako poslední, řeší konflikty.
<i>To je hezké, že jste teoreticky pojmenoval problém...</i>
Vývojář musí vidět problém a pokud ví, že ho nemůže hned fixnout, tak to má reportovat jako bug a po vydání opravy řešit, co s tím dál. Je to jeho práce a bez toho SW hnije.
Nevím, jestli to u M$ nereportují, nebo jestli ty reporty ignorují, aby měli manažeři krásnější grafy z bug trace systému, ale je fakt, že ten hnilobný zápach z Redmondu je cítit až sem. S tím opravfdu nic neudělám.
<i>Je hezké, že víte, jak byste psal Windows vy, ale tady se řeší jiný problém – Windows už existují, pár uživatelů je používá, byla v nich nalezena chyba, a teď je potřebu tu opravu co nejdřív dostat k uživatelům, pokud možno bez rozbití něčeho jiného.</i>
Rychlá distribuce oprav a minimum bugů by měl být u každýho SW (nejenom u Widlí) dlouhodobý cíl a dá se ho dosáhnout jenom tím, že se udržuje pořádek ve zdrojákách. Ostatně, starost o zdrojáky je jedna z mnoha povinností vývojářů a pokud to nedělají, jsou jako pekaři, kteří odmítají míchat těsto.
Btw, nejsou to teorie, 2 roky zpět jsem se certifikoval na agilní řízení SW projektů... A budeš se divit, opravdu to všechno jde, jenom chtít a myslet.