Jak wersjonować bibliotekę rozbitą na dwa moduły.

Przychodzę z pytaniem o radę.

Rozwijam sobie biliotekę https://t-regx.com/, i przymierzam się do rozbicia jej na dwa moduły, w taki sposób że jeden będzie zależał od drugiego.

I zastanawiam się jak się wersjonuje takie rzeczy, co jeśli wprowadzę zmieny w jednym albo w drugim? Czy wersjonuje się je po prostu zupełnie osobno, czy są jakieś lepsze sposoby na to?

Musisz to robić? Teraz pracuję nad apką, która zachowuje się w taki sposób, jaki Chcesz uzyskać, i już szykują się spajki i epiki, żeby to rozdzielić :-)

lion137 napisał(a):

Musisz to robić? Teraz pracuję nad apką, która zachowuje się w taki sposób, jaki Chcesz uzyskać, i już szykują się spajki i epiki, żeby to rozdzielić :-)

Biblioteka składa się jakby z dwóch entry pointów. Jeden składa się z około 100 klas i zapewnia dosyć niskopoziomowy dostęp do funkcjonalności. Drugi entrypoint korzysta z tego pierwszego, plus ma około 500 dodatkowych klas które zapewniają wysokopoziomowe operacje.

Teraz, ktoś kto chciałby użyć jedynie niskopoziomowych funkcji mógłby chcieć wczytać lżejszą wersję.

1. Czy chodzi Ci o wersjonowanie z punktu widzenia dewelopera, czy użytkownika?
2. Jeśli chodzi Ci o wersjonowanie z punktu widzenia użytkownika: w jaki sposób te moduły mają być dostępne dla użytkownika? Na przykład oddzielne pliki, paczki, wywołania API, coś innego?

Można razem, można osobno. Decyduje chyba to jak często te biblioteki będą używane razem a jak często osobno. Np cała akka jest wersjonowana razem. Za wyjątkiem akka-http.

A ja jeszcze pomyślałem o innej rzeczy, dzięki odpowiedzi @KamilAdam : o tym, czy planujesz rozwijać te moduły oddzielnie. Więc:

1. Wersjonuj oddzielnie, jeśli zarówno planujesz rozwijać moduł niskopoziomowy (ten "niezależący", jak rozumiem) oddzielnie od wysokopoziomowego, jak i zakładasz, że niektórzy użytkownicy zechcą pobierać tylko ten moduł, bez wysokopoziomowego.
2. Wersjonuj wspólnie, jeśli oczekujesz, że zawsze będą pobierać dwa moduły (i mieć zainstalowane? Nie wiem, jak to jest w PHP) – nawet jak zmienisz tylko jeden z nich.

@TomRiddle:

Biblioteka składa się jakby z dwóch entry pointów. Jeden składa się z około 100 klas i zapewnia dosyć niskopoziomowy dostęp do funkcjonalności. Drugi entrypoint korzysta z tego pierwszego, plus ma około 500 dodatkowych klas które zapewniają wysokopoziomowe operacje.

Teraz, ktoś kto chciałby użyć jedynie niskopoziomowych funkcji mógłby chcieć wczytać lżejszą wersję.

Jak to widzisz, ale chyba bym się skupił nad wystawieniem jednego interfejsu dla użytkownika.

lion137 napisał(a):

@TomRiddle:

Biblioteka składa się jakby z dwóch entry pointów. Jeden składa się z około 100 klas i zapewnia dosyć niskopoziomowy dostęp do funkcjonalności. Drugi entrypoint korzysta z tego pierwszego, plus ma około 500 dodatkowych klas które zapewniają wysokopoziomowe operacje.

Teraz, ktoś kto chciałby użyć jedynie niskopoziomowych funkcji mógłby chcieć wczytać lżejszą wersję.

Jak to widzisz, ale chyba bym się skupił nad wystawieniem jednego interfejsu dla użytkownika.

No właśnie nie mogę tego zrobić, bo ten wysokopoziomowy nie jest kompatybilny wstecz. Niskopoziomowy jest niskopoziomowy (mniej funkcji) ale za to jest backwards compatible. To jest powód czemu ludzie chcieliby go ściągać osobno.

@TomRiddle: dla użytkownika najlepiej rozwijać osobne wersje, bo w przeciwnym wypadku jak zrobisz zmianę w module wysokopoziomowym to niepotrzebnie stworzysz nową wersję biblioteki niskopoziomowej, która nic nie zmienia.

Jeszcze inaczej bym podszedł do sprawy (na razie odkładając na bok, co napisałem wcześniej).

Załóżmy, że wersjonujesz moduły oddzielnie, i że oba moduły mają taką samą wersję, x. Rozpatrzmy dwa przypadki:

1. Zmieniasz moduł niskopoziomowy. To pociąga za sobą zmianę jego wersji z x na x + 1. W takim razie jeśli ktoś zechce pobrać jedynie moduł niskopoziomowy, to nie ma problemu. Jeśli jednak ktoś zechce pobrać moduł wysokopoziomowy, to musi pobrać dwa moduły w dwóch różnych wersjach: moduł niskopoziomowy w wersji x + 1 oraz moduł wysokopoziomowy w wersji x; to może powodować pewne zamieszanie.
2. Zmieniasz moduł wysokopoziomowy. To pociąga za sobą zmianę jego wersji z x na x + 1. W takim razie jeśli ktoś zechce pobrać jedynie moduł niskopoziomowy, to nie ma problemu. Jeśli jednak ktoś zechce pobrać moduł wysokopoziomowy, to musi pobrać dwa moduły w dwóch różnych wersjach: moduł niskopoziomowy w wersji x oraz moduł wysokopoziomowy w wersji x + 1; to może powodować pewne zamieszanie.

Załóżmy teraz, że wersjonujesz moduły razem. W obu opisanych przypadkach zmiana wersji jednego pociąga zmianę wersji drugiego, więc użytkownik zawsze pobiera moduły o takich samych wersjach.

Dobrze myślę? @slsy ?

Z mojej perspektywy, to jeśli masz dwie biblioteki, z czego jedna jest niezależna a druga zależna od pierwszej, to wersjonujesz je osobno.

Ewentualnie, jeśli chcesz zachować jakąś zgrubną wspólną część, to trzymałbym się semantic versioning i trzymał kompatybilność między wersjami głównymi (choć to też się może okazać niepraktyczne, bo zmienisz coś w module zależnym, major tam skoczy o 1, a zależność pozostanie wersję do tyłu).

Generalnie ciężko powiedzieć na 100% nie siedząc w projekcie (bo jest pytanie jak często będą zmiany w poszczególnych, jak często przewidujesz użycie łączne vs tylko low-level), ale tak czy siak wydaje mi się, że więcej sensu jednak ma wersjonowanie osobne + sensowna dokumentacja w momencie kiedy coś się zmienia.

Ale pamiętaj żeby wrócić tu za rok i podsumować doświadczenia niezależnie od tego, co wybierzesz ;)

Silv napisał(a):

Jeszcze inaczej bym podszedł do sprawy (na razie odkładając na bok, co napisałem wcześniej).

Załóżmy, że wersjonujesz moduły oddzielnie, i że oba moduły mają taką samą wersję, x. Rozpatrzmy dwa przypadki:

1. Zmieniasz moduł niskopoziomowy. To pociąga za sobą zmianę jego wersji z x na x + 1. W takim razie jeśli ktoś zechce pobrać jedynie moduł niskopoziomowy, to nie ma problemu. Jeśli jednak ktoś zechce pobrać moduł wysokopoziomowy, to musi pobrać dwa moduły w dwóch różnych wersjach: moduł niskopoziomowy w wersji x + 1 oraz moduł wysokopoziomowy w wersji x; to może powodować pewne zamieszanie.
2. Zmieniasz moduł wysokopoziomowy. To pociąga za sobą zmianę jego wersji z x na x + 1. W takim razie jeśli ktoś zechce pobrać jedynie moduł niskopoziomowy, to nie ma problemu. Jeśli jednak ktoś zechce pobrać moduł wysokopoziomowy, to musi pobrać dwa moduły w dwóch różnych wersjach: moduł niskopoziomowy w wersji x oraz moduł wysokopoziomowy w wersji x + 1; to może powodować pewne zamieszanie.

Załóżmy teraz, że wersjonujesz moduły razem. W obu opisanych przypadkach zmiana wersji jednego pociąga zmianę wersji drugiego, więc użytkownik zawsze pobiera moduły o takich samych wersjach.

Użytkownik raczej nie będzie ściągał dwóch. Albo zainstaluje ten niskopoziomowy, albo ten wysokopoziomowy (który owszem ściągnie ten pierwszy).

Z moich osobistych doświadczeń wynika, że przyjemniej używa się bibliotek wersjonowanych razem, jeśli są w jakiś sposób od siebie zależne. Mniej czasu traci się na szukaniu kompatybilności pomiędzy bibliotekami.

TomRiddle napisał(a):

Silv napisał(a):

(…)

Użytkownik raczej nie będzie ściągał dwóch. Albo zainstaluje ten niskopoziomowy, albo ten wysokopoziomowy (który owszem ściągnie ten pierwszy).

Ale czy to na pewno różnica? Chodzi o to, że jeśli kiedyś spojrzy w wersje modułów albo na Twojej stronie, albo we własnym systemie, to zobaczy różnicę, gdyby były inne. Mnie chodzi o to, że nie miałby szans zobaczyć różnicy, gdyby jej nie było.