Jak se vypořádat s chybami v aktuální stable verzi?

Všechny ty fixy určitě budou ve 2.0.11, můžeš zkusit lobbovat za její urychlené vydání. Pokud to potřebuješ opravdu akutně, není tak těžké si přes git do 2.0.x cherry-picknout potřebné commity a do composer.json přidat své repository aby to composer tahal z tvého forku a ne z packagistu – takhle to řeším já v případě jiných knihoven než Nette.

Editoval enumag (18. 4. 2013 18:41)

ručním vyvěšením na packagist coby tharos/nette

To není třeba, stačí guthub repo a pár řádků navíc v composer.json.

Asi mi něco uniká :)

Nechce se mi kvůli tomu dělat fork Nette, do něj vyzobat opravy chyb a pak ho dávat na Packagist

Proč, lenost?

A nestálo by za to zavést nějaký robustnější model vydávání verzí a oprav?

Nějaký konkrétní nápad?

Vím, že to lze vyřešit forkem, cherry pickováním, ručním vyvěšením na packagist coby tharos/nette… ale připadá mi to zbytečně složité.

Proč, lenost?

Mrzí mě, že se jednou vydané verze už vůbec nijak nefixují.

Nechápu, tohle přece není pravda. Nebo ty žiješ ve světě, kde neexistují setinkové verze?

zase zavádí nové bugy v nových featurách…

V 2.0.x nejsou (téměř) žádné nové featury.

Přitom díky Gitu by zavedení nějakého lepšího modelu stálo jen malé úsilí.

Ty to řešení očividně znáš (fork, cherry pick, pull request…), ale přestože tvrdíš, že to stojí jen malé úsilí, tak ho odmítáš vynaložit. Proč by někdo jiný měl?

A co se týče konkrétně ndb, tak jsem měl za to, že je obecně známá věc, že verze 2.0.x jsou stabilní kromě ndb, kterou nikdo stabilizovat neumí :)

1. Forkneš Nette
2. založíš si větev, třeba fixed, na commitu na jakém chceš (takže třeba na tagu v2.0.10)
3. napickuješ si tam opravy jaké chceš
4. pushneš do svého forku
5. nakonfiguruješ Composer, aby instaloval Nette z tvého forku, pomocí sekce repositories
6. profit
7. když david vydá novou verzi, větev rebasuješ a opět křečkuješ opravy jaké potřebuješ
8. profit

"require": {
    "nette/nette": "dev-fixed as 2.0.99"
},
"repositories": [
    {
        "type": "package",
        "package": {
            "name": "nette/nette",
            "version": "fixed",
            "dist": { "url": "https://github.com/Tharos/nette/archive/fixed.zip", "type": "zip" },
            "source": { "url": "https://github.com/Tharos/nette.git", "type": "git", "reference": "fixed" },
            "autoload": { "files": ["Nette/loader.php"] }
        }
    }
]

Každá verze jakéhokoliv software chyby opravuje a zároveň vytváří nové. Tomu se nevyhneš, ani kdybys každou RC verzi půl roku testoval.

Šaman napsal(a):

WTF? Jestliže stable verze obsahuje chyby, o kterých se ví a existuje na to oprava v develop verzi, tak je dost odvážné tvrdit, že uživatelé jsou líní si sami vyzobat příslušné opravy. Není snad snahou autorů dodávat kód s co nejmenším počtem chyb?

Good point. Když se napíšou opravy závažných chyb, měl by se udělat tag… (Ještěže ndb nepoužívám :))

Abych to upřesnil, mluvím hlavně o chybách Nette\Database.

Pak věz, že nevím o nikom, kdo by tu knihovnu dokázal stabilizovat. Je to známý fakt a z mého pohledu tvoje blbost, že ses ji rozhodl používat. Já od ní odrazuji lidi od té doby, co je v Nette. Žádný způsob vydávání verzí neřeší to, že to prostě nikdo neumí řešit. @hrach (a samozřejmě i další) odvedl obrovské množství práce, ale ani přes jeho obrovskou snahu ta knihovna prostě není ani zdaleka tak stabilní jako dibi.

Nechce se mi vyzobávat chyby, protože Nette\Database v dev verzi není zpětně kompatibilní s verzí 2.0.10, takže bych u každého toho cherry-pickovaného commitu musel řešit, jestli je kompatibilní s Nette 2.0.10 a případně ho upravovat.

Takže přece lenost. Přesto to už někdo zcela zdarma (@dg) 10× udělal, ve snaze ten problém řešit.

No, já aktuálně většině svých projektů používám tuhle metodu větvení/verzování (myslím, že dost známou) a v ní je tohle elegantně vyřešené.

Viz výše, tohle v podstatě nic neřeší. NDB nikdo stabilizovat neumí (nebo rozhodně ne v krátkém čase). Ve snaze se stabilitě přiblížit bylo potřeba provést zpětně nekompatibilní změny v NDB, které jsou často neportovatelné do 2.0.x.

Plánovaná další vydaná verze je v mnohých věcech zpětně nekompatibilní s verzí 2.0.10.

Z velké části právě proto, že se někdo snaží řešit to, že sis vybral nestabilní knihovnu, viz výše.

Pokud na nějaký svůj projekt nasadím verzi z masteru, výsledkem je šňůra fatal errorů a čas investovaný do úpravy kódu…

Zpětně nekompatibilních změn ve 2.1 je překvapivě poměrně málo. Největší problém bude asi (já tomu nerozumím) s NDB, důvody viz výše.

Šaman wrote:
WTF? Jestliže stable verze obsahuje chyby

A reportuješ ty chyby poctivě do issue trackeru? Každá stable verze je vydávána v dobré vůli, že žádné chyby neobsahuje. Před vydáním nové stable verze je k dispozici release candidate k otestování. Testuješ poctivě každý release candidate, že funguje bez problémů s tvým kódem?

je dost odvážné tvrdit, že uživatelé jsou líní si sami vyzobat příslušné opravy.

Ne vždy je možné ty opravy snadno naportovat. Domníváš-li se o opaku, tak si je neportuj.

P.S. Ještě jsem nepracoval pro klienta, kterému by nevadilo, že si používám vlastní upravené Nette.

Od kdy klient rozhoduje, jakou verzi frameworku použít?

při pokusu o upgrade se opupínkuju.

Pochopitelně je potřeba mít zkušenosti s merge/rebase.

@enumag: Nikdo vám nebrání (pokud vím) dělat pull requesty s opravami vůči release-2.0.x. Setinkové verze navíc vychází poměrně často.

Jan Tvrdík napsal(a):

Jak jsem psal… Tohle je pro mě typický pohled člověka, který se aktivně podílí na vývoji Nette a frameworkem takříkajíc „žije“. Kolik takových lidí ale je?

Já Nette chci používat a ne spoluvyvíjet. Je to špatně? Jsem sobec/línej/whatever?

Editoval Tharos (18. 4. 2013 23:18)

Jan Tvrdík napsal(a):
Pak věz, že nevím o nikom, kdo by tu knihovnu dokázal stabilizovat. Je to známý fakt a z mého pohledu tvoje blbost, že ses ji rozhodl používat. Já od ní odrazuji lidi od té doby, co je v Nette. Žádný způsob vydávání verzí neřeší to, že to prostě nikdo neumí řešit. @hrach (a samozřejmě i další) odvedl obrovské množství práce, ale ani přes jeho obrovskou snahu ta knihovna prostě není ani zdaleka tak stabilní jako dibi.

Jestlize to je znamy fakt, tak co teda NDB dela v nette? Nekdo se s tim nauci pracovat, zalibi se mu to a zacne to pouzivat. Pak zjisti, ze to je vlastne nestabilni a nefunkcni..

Pohled mnohých z vás tady je typický pro lidi, kteří denně sledují vývoj frameworku, na GitHubu čile komentují, mají o dění kolem frameworku extrémně velký přehled. Jasně, jejich rada je: „Udělej si fork, vyzobej si co potřebuješ, hoď si to na Packagist a… profi!“

Už jsem řekl že na packagist to dávat nemusíš.

Jenomže pak je tu ještě 99 % dalších uživatelů Nette, kteří vývojem frameworku tolik nežijí, sledují jen changelog na fóru, nevládnou Gitem, neumí s GitHubem, nepoužívají Composer… No a tihle chudáci jsou odsouzeni používat silně zabugované „stable verze“, protože po jejich vydání se s tou danou verzí už nic neudělá a další oficiálně vydaná verze má řadu BC breaků.

Tihle chudáci by se měli s gitem a composerem naučit, chtějí-li se stát dobrými a dobře placenými programátory. Stable verze nejsou silně zabugované – jak už tady zaznělo, každá stable verze je vydávána s vírou že neobsahuje žádné bugy nebo alespoň žádné takové které lze vyřešit bez BC breaku.

Tvůj pohled je dle mého názoru silně zkreslený tou Nette\Database – narazils ve stable na problémy v jiných částech frameworku? Jak jistě víš, Database je nejmladší část Nette a navíc poměrně komplexní, nedivím se tedy, že není až tak stable. Osobně považuji používání NDB ve stable Nette za sebevraždu – a podotýkám že narozdíl od @Jan Tvrdík jsem spokojeným uživatelem NDB.

Fakt mi nejde do hlavy, jak s tímhle můžete být spokojení a považujete těch 99 % zbylých lidí za líné…

V tomhle s tebou souhlasím. Jak už řekl Šaman, naší snahou je dodávat nezabugovaný kód a nenutit těch 99% k forkování a podobným věcem.

@enumag: Přečti si kdyžtak i ten článek k tomu, ne vše se tam dá vyčíst z obrázku. Přijde mi, že jsi tu pointu nepochopil (a nemyslím to nijak ve zlém, snažím se být konstruktivní). Podle toho modelu neexistuje nic jako „větev 2.0.x“. Bugfixy se typicky vyvíjejí v samostatné hotfix větvi oddělené z posledního commitu v masteru. A pak už jde jen o to mergnout je zpět do masteru a navíc ještě i do develop větve (respektive do release větve, pokud tou dobou nějaká existuje – staré se typicky odmazávají).

Kritiku vždy rád přijímám, ale obávám se že jsi to nepochopil ty. Na tom obrázku je přímo „release brancheS“ (ty zelené commity) a tím není ani náhodou myšlena jedna jediná větev, ale jedna větev za každou major verzi – přesně jak to má Nette. Článek jsem nečetl ale ten obrázek v tomhle mluví naprosto jasně.

Bugfixy jsem už předtím z obrázku pochopil přesně tak jak píšeš, možná jsem se špatně vyjádřil.

Dále nevím, co by to bylo za fix, který způsobuje BC break. Fix je oprava něčeho, aby se to chovalo podle očekávání, tj. aby to vyhovovalo tomu, jak se to už před tím fixem lidi snaží používat.

Některé problémy jsou způsobené špatným návrhem a tím že lidi občas něco používají jinak než původně bylo zamýšleno.

Editoval enumag (19. 4. 2013 13:40)

Za těchto okolností si myslím, že integrace NDatabase v Nette je chyba. Nevím, proč David změnil názor (Dibi byla samostatná knihovna, aby měl uživatel svobodný výběr databázové vrstvy).
Teď, když je NDatabase součástí frameworku a všechny návody s ní počítají, tak se to každý nováček naučí používat (kecám, nenaučí, naučí se maximálně traverzovat mezi tabulkami, na zbytek se ptá) a pokud nemá dobrý důvod na ni zanevřít, tak se ji snaží používat.

Já si nad NDatadase zkusil dva projekty, jeden relativně bez problémů (když nepočítám problematickou dokumentaci, hackovaný left joiny a některé věci stále neumím), na druhém projektu byl výkonnostní problém s AcriveRow. (Zkusil jsem Fabik\Database, pak YetORM a lagy se vyřešily až odstraněním ActiveRow z Entity. Koneckonců, že aktivní entita je antipattern jsem věděl od začátku, ale nedbal jsem.) Takže dobrý důvod zanevřít NDatabase mám, stálo mě to ale dost času i nervů.

Druhá věc, která mi maličko vadí je ta, že pomalu zapomínám SQL syntax, takže když pak dojde na optimalizaci dotazu a databázová vrstva na to nestačí, tak mi najednou chybí základní programátorská abilita, kterou jsem s Dibi vždy měl. Takže Resumé je návrat ke kořenům.

ja NDB vnimam jako neco pro zacatecnika (zatim). par jednoduchych selectu, zaiterovat si v sablone a easy web je na svete. a konec :) pokud to naroubujes na neco sloziteho a najednou po ni chces nejake megajoiny a dalsi kraviny, nevybral sis dobre. ja si ndb zkusil a zjistil, ze delam slozitejsi aplikace nez ndb zvladala nejak jednoduse a bez chyb a sahl po dibi. ale pak sem delal nejaky jednoduchy webik a tam sem si ndb klidne dal, pro tu jednoduchost.

staci se zamyslet a pouzit spravnou vec na tu spravnou situaci :)

Glottis napsal(a):

staci se zamyslet a pouzit spravnou vec na tu spravnou situaci :)

To samozřejmě ano, ale kdyby knihovna Nette\Database dělala to, co má (tj. nebyla zabugovaná), byla by správnou věcí pro mnoho situací. Rozsáhlé projekty (kdy se vůbec projekt stává rozsáhlým?) jsou stejně víc o kvalitním zapouzdřením modelu a pak už je kosmetická věc, jestli je v útrobách Dibi/NDB/whatever.

Moje resumé po diskuzi, která zde proběhla (a za kterou jsem moc rád), je následující…

Pokud si odmyslím NDB, musím uznat, že stable Nette je opravdu stable. Pokud bych NDB nezkoušel používat, stopro bych tohle vlákno vůbec nezakládal.

Že je NDB součástí Nette taky vidím jako nešťastné a to hned z několika důvodů.

NDB ještě není ustálená knihovna a zasloužila by si kratší release cyklus, než má Nette. V tomhle by její osamostatnění velmi pomohlo.

Dále je teď myslím vůbec tendence rozdělit Nette do samostatných balíčků (Tracy…). Pak bych osobně NDB vyčlenil jako první. :-P

Díky všem za cenné odpovědi, pomohli jste mi urovnat si pár věcí v hlavě.

NDB ještě není ustálená knihovna a zasloužila by si kratší release cyklus, než má Nette. V tomhle by její osamostatnění velmi pomohlo.

+100! :-)

Dále je teď myslím vůbec tendence rozdělit Nette do samostatných balíčků (Tracy…). Pak bych osobně NDB vyčlenil jako první. :-P

Tento návrh se tu již několikrát objevil. Bohužel to není tak jednoduché, protože Database má závislost na Caching.