[Erp5-poland] robienie upgrade - różne notatki i myśli

[Łukasz Nowak]

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.