On Fri, Jun 29, 2012 at 09:59:42PM +0200, Jacek Konieczny wrote: > On Fri, Jun 29, 2012 at 06:57:55PM +0200, Paweł Sikora wrote: > > no to jak panowie, jaki w koncu model odgalezien przyjmujemy dla glownego > > nurtu pld-th? > > > > 1). > > dzialamy na 2 galeziach master/devel ze wzajemnym scalaniem (tak jak > > pokazalem wyzej) > > i nie nadpisujemy/kasujemy devel. > > Czemu się tak ograniczać? Można rozwijać pakiet w różnych kierunkach > przecież. 'devel' nic nie mówi i nawet nie wiadomo co tam miałoby być. > > > 2). > > dla kazdej kolejnej developerskiej wersji softu odgaleziamy od master do > > jakiegos next-X.Y > > (czy jak to tam nazwiemy), potem merge do master i koniec uzywania galezi > > (kasacja?). > > Wybieram tę opcję. Topic branch. W tym przypadku 'topikiem' jest jakieś > developerskie wydanie softu. > > Bo mergowaniu takiego brancha do master, gdy wersja staje się aktualną > lub przestarzałą, to IMHO można go skasować ??? znaczy usunąć nazwę z > repo, bo w historii odgałęzienie zostanie. > I nie będzie problemów jak z resetem 'uniwersalnego' brancha 'devel', że > po jakimś czasie ktoś robi 'git pull' i bzdury wychodzą. > > > chodzi o to, zeby nie bylo pozniej w kazdym pakiecie wedle lokalnych > > upodoban, > > bo jakikolwiek nowy developer zglupieje, albo wprowadzi swoj odmienny tok > > dzialania. > > Dla częstych przypadków, jak pakiet z developerską/testową wersją softu > dobrze jest ustalić jakieś reguły. IMHO wystarczy numer wersji jako > nazwa brancha.
IMO lepszy byłby schemat nazw pozwalający od razu odróżnić charakter gałęzi (wersje rozwojowe, wersje stabilne starsze niż master itp.), bez oglądania historii gałęzi/wersji przed i po odgałęzieniu. O ile w danej chwili może być oczywiste, co jest wersją rozwojową, a co starą stabilną - to po paru latach już nie. -- Jakub Bogusz http://qboosh.pl/ _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
