From lukasz.nowak w ventis.com.pl Mon Jun 16 10:59:34 2008 From: lukasz.nowak w ventis.com.pl (=?UTF-8?B?xYF1a2Fzeg==?= Nowak) Date: Mon, 16 Jun 2008 10:59:34 +0200 Subject: [Erp5-poland] =?utf-8?q?robienie_upgrade_-_r=C3=B3=C5=BCne_notatk?= =?utf-8?q?i_i_my=C5=9Bli?= Message-ID: <20080616105934.571637b0@faun> Witam, Robię upgrade. Z prehistorycznej rewizji 15401 do version-5.0 20734. Idzie nawet, nawet :) Ponieważ upgrade'y warto robić co pewien czas, a brakuje mi jakiegoś howto to rodzą mi się w głowie różne pomysły, a większość z nich pewnie wynika z mojej nieznajomości ERP5 czy też metodologi prowadzenia w projektów w ERP5. Mam taki obecny scenariusz: - napisane testy na rewizję 15401 [OLDTEST] - uruchamiam autotester na version-5.0 [NEWTEST] - staram się doprowadzić to tej samej ilości błedów i niepowodzeń na NEWTEST i OLDTEST - nie używam branchingu - kod ma działać poprawnie na obydwu wersjach - używam BTek ventis_base_patch, które są obecne tylko na OLDTEST W miarę się udaje. Parę wolnych myśli, które wypłynęły podczas tej mord...miłej pracy :) - robienie monkey patchy nie ma czasem sensu, ale... Dlaczego? Bardzo trudno (przynajmniej dla mnie) rozpoznać z poziomu produktu, że patch nie ma być jednak nałożony (Note: nie chcę się opierać na tricku w stylu - pobierz wersję SVN produktu ERP5 :) ). Lepiej już PropertySheeta, Document czy coś innego włożyć do BTki ventis_coś_patch, która nie będzie używana na NEWTEST Ale...jeśli mimo to, nie doszło do poprawienia, rozszerzenia czegoś, co można w BTce mieć (np. Document), to gimnastykuję się, aby mój plik działał tu i tu - no i składa się z setek ifów. Gorzej jest z tymi klasami, których nie da się bezpośrednio w BTce mieć - np. MovementGroupy - wtedy jest ostra jazda, szczególnie, jak np. pojawi się MovementGroup z taką samą nazwą, jaką ja mam, ale działa inaczej. Jeszcze nie mam sensownego rozwiązania. Czasem jest tak, że mój monkeypatch nie jest do końca kompatybilny z nowym plikiem. A ma działać na obydwu wersjach. Tak sobie myślę, aby mieć dwa produkty - jeden na OLDTEST, drugi na NEWTEST, ale to już branching i code duplication :( - trzeba mieć jedną gałąź kodu Tak przynajmniej mi się wydaje. Niektóre upgrade są procesem, co trwa, trwa i trwa dłużej niż smak góry orbit. A nasi kochani użytkownicy [tm] mają niesamowitą zdolność znajdowania krytycznych problemów w systemie, akurat w momencie, kiedy się bierzemy za upgrade. Zrobienie brancha powoduje double-commiting, bleee, nie da się tego opanować (tak zrobiłem ostatnio, po prostu odpowiedzią było: niestety, nie teraz - nie porysowali mi samochodu, bo są naprawdę wyrozumiali). - problemy z backward incompatibility changes w core Zdarzają się niestety. Staram się je raportować, ale wtedy commit już wylatuje poza moją version-5.0. Nie wiem czy jestem w stanie robić upgrade do HEADa, z założeniem co chwilowego upowania - co dzień czy co dwa dni. Wtedy piszę nowego patcha, który backportuje co dodano do core na moje własne życzenie :) Chętnie poczytam o waszych problemach, doświadczeniach i success-case'ach związanych z upgrade'owaniem. Pozdrawiam, Łukasz -- Łukasz Nowak R&D Ventis http://www.ventis.com.pl/ tel: +48 32 768 16 85 fax: +48 32 392 10 61 ``Use the Source, Luke...'' I am only craftsman.