Vydání Nette 2.1 do konce roku s maximálním zachováním BC

Co bych rád viděl ve 2.1 (návrh)

• nové definice latte blocku {#content}

Budu předpokládat, že to David schválí a rovnou nastíním časový plán.

• Do konce tohoto týdne (tj. do 2. 12. 2012) by proběhlo přejmenování 2.1-dev na 2.2-dev (nebo rovnou 2.5-dev?) a do větve release-2.1.x by se naházely příslušné commity z masteru a vyšla by 2.1.0-beta1.
• Pokud by nikdo neměl výraznější námitky (které by případně vyústily ve verzi 2.1.0-beta2), tak by týden na to (tj. do 9. 12. 2012) vyšla verze 2.1.0-rc1, na kterou už doporučíme firmám migrovat s tím, že pokud by narazily na nějaký problém, tak ho do verze 2.1.0 vyřešíme.
• Zároveň by s vydáním verze 2.1.0-rc1 začaly úpravy dokumentace (nemělo by jich být moc), které musí být hotové před vydáním finální 2.1.0.

Co brání zahrnutí těchto změn to 2.0.*? Připadá mi, že tam nejsou žádné BC breaky, spíše přidané fce (možná kromě BaseControl::$idMask).

EDIT: @mkoubik: Co z toho odporuje definici „neškodná změna“? :-)

Editoval enumag (28. 11. 2012 17:54)

enumag wrote:

Co brání zahrnutí těchto změn to 2.0.*? Připadá mi, že tam nejsou žádné BC breaky, spíše přidané fce (možná kromě BaseControl::$idMask).

Přečti si něco o sémantické, verzování. Dozvíš se, že nové feature a žádné bc breaky je přesně to, co patří do minor verzí.

Co z toho odporuje definici „neškodná změna“? :-)

Příklad: přidání Presenter::sendJson() vypadá jako jednoduchá změna, co nezpůsobí BC break, že? Omyl! Všem firmám, které si implementovali svoji vlastní metodu sendJson s jinou signaturou se rozbije aplikace ⇒ nelze zařadit do 2.0.x.

Jan Tvrdík napsal(a):
Příklad: přidání Presenter::sendJson() vypadá jako jednoduchá změna, co nezpůsobí BC break, že? Omyl! Všem firmám, které si implementovali svoji vlastní metodu sendJson s jinou signaturou se rozbije aplikace ⇒ nelze zařadit do 2.0.x.

Na tuhle logiku by se dalo naroubovat, že je BC break úplně všechno.

Zásadní jsou třeba i DI továrničky.

Zásadní ano, otázka jestli jsou dostatečně hotové.

Dle mého názoru nejsou.

Smysl je v tom, aby ti, kteří chtějí používat stable verzi, nebyli ochuzeni o nové featury.

@DavidGrudl:

zároveň se po mě bude chtít udržovat paralelně mnohem více větví, což rozhodně nemám chuť.

To, že je udržování verzí tvoje starost, je důsledek tvojí volby. Bylo ti navrženo, že by vnikla jasně definovaná množina právnických (primárně) a fyzických osob, která by se o to starala. Navíc ne všechny minor verze se musí udržovat stejně dlouho, říká se tomu LTS.

Přísně semantické verzování má i stinné stránky.

To tady ani nikdo nenavrhuje. Nicméně věřím, že teď máme rozumně nakročeno a bojím se, že odkročíme špatným směrem (vydání 2.1 za dlouho a se spoustu BC breaků).

Každopádně nevidím smysl v tom vytvářet novou verzi kvůli pár drobnostem.

Souhlasím s tím, že pokud není PresenterFactory::$mapping a vylepšený debugger dostatečně stabilní, tak klesá potřeba vydat novou verzi. Nicméně pořád si myslím, že to má smysl především jako účinná obrana proti kroku špatným směrem.

Na druhou stranu nevidím reálně, že by přišla komunita a oznámila ti, že to přebírá :)

Tohle je imho diskuze na nějakou posobotu/hackaton.

@zool: Z mého pohledu špatně. Už tu několik měsíců měla být a ještě několik (zkusím hádát – 6) tu nebude.

@**David Grudl**: Nějaké přibližné datum by nebylo? Rozjíždim nový projekt, ale na 2.0.x už ho začít nechci a na 2.1-dev moc také ne, jelikož se razantně změnilo několik věcí a já kvůli tomu musel velkou část přepsat. Tzv. začínat něco na dev … z toho už jsem vyléčen.

Děkuji :)

Přečtěte si název vlákna „Vydání Nette 2.1 do konce roku s maximálním zachováním BC“ a neptejte se tak blbě :P

Editoval xificurk (22. 5. 2013 16:43)

@xificurk: Důležité je připomenout, že vlákno nezaložil David.

Release 2.1 je velmi blízko, postupně už se sestavuje i rel. announcement.

Editoval Majkl578 (22. 5. 2013 16:51)

Bylo by možné do Nette přidat alias barDump pro rychlé dumpování do debug baru?
Teď mám (a pokud vím tak nejsem sám) v bootstrapu následující kód:

<?php
function barDump($var, $title='')
{
    $backtrace = debug_backtrace();
    $source = (isset($backtrace[1]['class'])) ?
        $backtrace[1]['class'] :
        basename($backtrace[0]['file']);
    $line = $backtrace[0]['line'];
    if($title !== '')
        $title .= ' – ';
    return Nette\Diagnostics\Debugger::barDump($var, $title . $source . ' (' . $line .')');
}
?>

Funguje to dobře, ale radši bych to měl přímo ve frameworku, stejně jako dump (který používám méně, než barDump).

taky bych tam rad neco takoveho mel a implmentace je mi burt, hlavne ze to propadne do baru

enumag napsal(a):

@Šaman: A pokud někdo používá trochu jinou implementaci než ty? ;-) Za mne –1.

@Šaman: S tím souhlasím, ale vzhledem k tomu že si tu funkci definuje každý trochu jinak jsem proti tomu dávat nějakou implementaci přímo do Nette.

enumag: Jak definuje různě? Já chci místo dlouhého zápisu

<?php
Nette\Diagnostics\Debugger::dump($var);
Nette\Diagnostics\Debugger::barDump($var, $title);
?>

použít alias

<?php
dump($var); # funguje
barDump($var, $title); # nefunguje - proč?
?>

Jak to bude definované mi je jedno. Jenom upozorňuji na funkci, která mi chybí natolik, že si ji definuji ručně v bootrapu. Nepředpokládám, že by to byl problém začlenit do Nette.

Njn, to už ale není čistý alias k Nette\Diagnostics\Debugger::barDump($var, $title)
Chápu, že pro tebe by to znamenalo určitý BC, ale současné chování Nette mi připadá nekonzistentní (dump vs barDump). A možná ještě fireLog, ale ten mě nepálí.
Ta různá implementace podle mě vznikla čistě jen proto, že si to každý psal po svém (přesě jak píše Glottis), mě by třeba vůbec nevadilo, pokud by se barDump choval podle tvé implementace (jen by se tak musel chovat i Nette\Diagnostics\Debugger::barDump)

Ok, počkám jestli se k tomu bude ještě někdo vyjadřovat. Chtěl jsem to pushnout, ale když nevím, jestli by o tom byl zájem, tak se nejdřív ptám.

Editoval Šaman (3. 7. 2013 18:33)

ma niekto z vas nejake aktualne info ohladom vydania v2.1? Ze co tam chce David este zahrnut a ani sa nepytam radsej na datum :)

enumag wrote: Čekat na tuhle feature až do 2.2 bych opravdu nerad.

Uvědomuješ si, že doba čekání je v obou případech téměř identická?

určitě dojde k vydání těchto minoritních verzí? David na anglickém fóru psal, že dojde rovnou k vydání nette fw 3.0

Patrik Votoček napsal(a):

David na anglickém fóru psal, že dojde rovnou k vydání nette fw 3.0

kde?

http://lmgtfy.com/?…

@David Grudl: +1 Jen bych ve 2.1 rád viděl ještě pár věcí které v masteru zatím nejsou.

Co přesně znamená „automatické volání method inject v DI“?
Jedu na @dev verzi a nevím už přesně, co všechno je ve @stable jinak. Inject metody a autowiring používám, pokud by se v tomhle oproti aktuální @dev něco změnilo, asi by to pro mě byl problém.

Jinak +1 za aktuální stable verzi. Už od 2.05 jedu na vývojové verzi a při každém upgradu se bojím, jestli se něco nerozbije. Za mě by bylo úplně ideální vytvořit ještě jednu větev, kam by se průběžně zaváděly již odladěné funkce, ale která by nebyla konzervativní a nemusela za každou cenu držet BC. Pak by byla vývojová (s reálným nebezpečím chyb a změn v API), stabilní (ustálené API, při BC by se verze zvýšila o desetinu) a konzervativní (viz současná 2.0.x).

V současnosti musím mít Nette součástí repozitáře, protože kromě hashe nevím, na jakou verzi mám vlastně program odladěný – 2.0× mi nestačí (mám minimálně 3 důvody použít 2.1) ale vývojová verze přecijen není vhodná na ostré nasazení.

enumag napsal(a):

@Šaman: V Nette 2.0 se inject metody volaly jen na presenterech, ve 2.1 se volají na všech službách.

A nešla by přidat možnost toto chování (inject na všech službách) někde zapnout? Používám to sice v jediném případě (inject nepovinného TemplateLocatoru do komponent), ale nerad bych to dával do konstruktoru (komponenta může existovat i bez něho) a pro každou komponentu nastavovat stejný setter se mi také nechce (používám ho všude).

A propo podpora property injection v presenterech pomocí anotace zůstane?