Czy powinny być publiczne wersje oprogramowania 0.x.x?

3
somekind napisał(a):
jarekr000000 napisał(a):

Gdzie, po prostu - jeśli raz wypuściłeś jakąś wersję to możesz założyć, że ktoś z tej wersji korzysta - i nie masz na to wpływu. I jeśli taką wersję usuniesz to robisz problem nie tylko użytkownikom, ale i potencjalnie sobie (!!!). Choćby dlatego, że nie da się potem łatwo sprawdzić, że problem został naprawiony w nowej wersji (skoro nie da się odpalić starej dla porównania).

To nie jest żaden problem, usunięcie paczki nie oznacza usunięcia historii źródeł.
Tylko zauważ, że ja piszę o usuwaniu poprzednich wersji major, więc to nie jest "naprawienie problemu", tylko niekompatybilne zmiany w sposobie działania. (Np. zmiana sposobu uwierzytelniania w jakiejś usłudze.) Tu nie ma czego porównywać, bo stara wersja nie będzie już działać, a nowa może mieć nowe problemy.

cały czas piszesz o tym, że usuwasz stare wersje, bo stare wersje nie działają. pewnie jedyne co wypuszczasz to jakieś klienty do restowego api, które regularnie wyrzucasz na śmietnik. w takim razie to bardzo specyficzny rodzaj bibliotek. cała reszta ludzi tutaj ma na myśli biblioteki zupełnie inne niż klienty do api.

oryginalnie ten wątek jest o tym czy usuwać prawdopodobnie stare wersje biblioteki https://github.com/T-Regx/T-Regx (chociaż to nie jest specjalnie ważne). dlaczego stara wersja biblioteki do regexów miałaby nagle przestać działać? generalnie jakieś 99% zależności, które ściągam z publicznych repozytoriów artefaktów to nie są klienty do (restowego) api, tylko rzeczy które działają cały czas. jak skompiluję kod w c# sprzed kilkunastu lat, który obrabia regexy to to nadal będzie się budować i działać. dlaczego ktoś miałby to psuć usuwając zależności z repozytoriów?

2
Wibowit napisał(a):

generalnie jakieś 99% zależności, które ściągam z publicznych repozytoriów artefaktów to nie są klienty do (restowego) api, tylko rzeczy które działają cały czas. jak skompiluję kod w c# sprzed kilkunastu lat, który obrabia regexy to to nadal będzie się budować i działać. dlaczego ktoś miałby to psuć usuwając zależności z repozytoriów?

I tutaj opisałeś cały problem. Tak naprawdę na pytanie "czy powinny być publiczne wersje oprogramowania 0.x.x?" odpowiedź brzmi "to zależy". Jeśli chodzi o rozmaite libki typu biblioteki czy frameworki to:

  1. Jeśli biblioteka nie będzie działała nigdy w nowszej wersji to nie ma sensu jej trzymać. Jestem w stanie zrozumieć dostawcę jakiegoś API RESTowego, który dorzuca gratisowo np. JARa, dzięki któremu nie trzeba samemu wołać serwera, a odpowiedzi przychodzą elegancko upakowane w obiekty. No i pytanie - czy jeśli powstanie nowa wersja API, a stara wersja zostanie wyłączona to czy trzeba trzymać taką libkę? IMO nie - oramy i do kosza.
  2. Druga kwestia to właśnie biblioteki, które są z braku lepszego słowa "samodzielne", tzn. nie mają zależności zewnętrznych. Tutaj je bym zostawiał, bo po prostu nie widzę powodu, by je usuwać.
7
wartek01 napisał(a):

Tak naprawdę na pytanie "czy powinny być publiczne wersje oprogramowania 0.x.x?" odpowiedź brzmi "to zależy".

oryginalne pytanie było "czy usuwać wersje starsze niż 1.x.x" czy jakoś tak, ale @Riddle zrobił nam wszystkim kuku i zmienił pytanie w ankiecie już po oddaniu mnóstwa głosów

  1. Jeśli biblioteka nie będzie działała nigdy w nowszej wersji to nie ma sensu jej trzymać. Jestem w stanie zrozumieć dostawcę jakiegoś API RESTowego, który dorzuca gratisowo np. JARa, dzięki któremu nie trzeba samemu wołać serwera, a odpowiedzi przychodzą elegancko upakowane w obiekty. No i pytanie - czy jeśli powstanie nowa wersja API, a stara wersja zostanie wyłączona to czy trzeba trzymać taką libkę? IMO nie - oramy i do kosza.

no tutaj jest jakiś tam sens usuwania, ale i tak samo usuwanie to dodatkowa (i raczej zbędna) robota. należy tutaj podkreślić, że tego typu biblioteki to nisza w niszy (jeśli chodzi o te publicznie dostępne), więc stawianie ogólnego (tzn. dotyczącego przynajmniej z pozoru wszystkich rodzajów bibliotek) twierdzenia "stare wersje bibliotek należy usuwać z repozytorium" na podstawie tak niszowego zastosowania (biorąc pod uwagę % tego typu bibliotek w całym ogóle) jest rażącym błędem.

3

Ad klienty do api: imo wyrzucanie takiego klienta nawet do już wyłączonego api też może być niefajne, istnieje sporo systemów spaghetti, w których wiszą od dawna nieużywane zależności, ale nikt nie odważa się tego dotknąć, więc usunięcie nawet niedziałającego pakietu z repo może popsuć buildy.

5
somekind napisał(a):

Nie. Ja po prostu uważam, że trzymanie historii śmieci nie ma sensu.
To jak z kodem - jak przestał spełniać swoją funkcję, to go usuwam.

To nie działa przy bibliotekach dostępnych publicznie. Jeśli piszesz bibliotekę i dodajesz ją do jakiegoś registry package managera i piszesz, że biblioteka jest dostępna do użycia a nagle ją usuwasz, to prawdopodobnie rozwalisz kilka-kilkaset projektów.

Być może, tego nie oceniam, bo nie znam tych paczek.
Po prostu dziwne dla mnie jest to tutejsze przywiązanie do historii. Dziwne i zwyczajnie niebezpieczne.

Tj wyżej, jeśli ustawiasz historię biblioteki i udostępniasz jej pobieranie to dlaczego miałbyś ją usuwać? Jakie są powody? :)

Jak ktoś mi usuwa paczki to raczej omijam autora. Mało stabilny człowiek == mało stabilny projekt :) Ewentualnie hostuję sobie historię w registry sam :)

Co innego jeśli faktycznie piszesz, że to wersje testowe i zostaną usunięte.

@Riddle: Ani laravel ani phpunit nie usuneli paczek, po prostu zaczeli je dodawać do packagista później, ale to nie sprawia, że coś zostało usunięte bo tagi wciąż są dostępne więc jeśli ktoś wcześniej budował sobie paczkę ze źródeł, albo zaciąga paczki z gita zamiast packagista to wciąż ma taką opcję:

https://github.com/laravel/laravel/tags?after=v3.2.4

0
Wibowit napisał(a):

cały czas piszesz o tym, że usuwasz stare wersje, bo stare wersje nie działają. pewnie jedyne co wypuszczasz to jakieś klienty do restowego api, które regularnie wyrzucasz na śmietnik. w takim razie to bardzo specyficzny rodzaj bibliotek. cała reszta ludzi tutaj ma na myśli biblioteki zupełnie inne niż klienty do api.

Tak, nie wiesz gdzie i przy czym pracuję, a wiesz jakie paczki wypuszczam. xD
Weź rzuć tego Swinga i Javę 1.2, bo teraz paczki do API wypuszczają się same w procesie CI.

Wibowit napisał(a):

stawianie ogólnego (tzn. dotyczącego przynajmniej z pozoru wszystkich rodzajów bibliotek) twierdzenia "stare wersje bibliotek należy usuwać z repozytorium"

A ktoś postawił tutaj taką tezę?

daniel1302 napisał(a):

To nie działa przy bibliotekach dostępnych publicznie. Jeśli piszesz bibliotekę i dodajesz ją do jakiegoś registry package managera i piszesz, że biblioteka jest dostępna do użycia a nagle ją usuwasz, to prawdopodobnie rozwalisz kilka-kilkaset projektów.

Ale wiesz, ja jestem świadom konsekwencji. I te konsekwencje są de facto celem takiego działania.
Nie chodzi przecież o usuwanie każdej poprzedniej wersji, tylko tych z poprzedniego majora, jeśli jest ku temu powód. Powodem może być też to, że sponsor tego chce.

1
somekind napisał(a):
Wibowit napisał(a):

stawianie ogólnego (tzn. dotyczącego przynajmniej z pozoru wszystkich rodzajów bibliotek) twierdzenia "stare wersje bibliotek należy usuwać z repozytorium"

A ktoś postawił tutaj taką tezę?

ty. no chyba, że chciałeś się pochwalić, że usuwasz, a nie że inni mają usuwać. nie wiadomo o co ci chodzi. masz jakieś tam koszty i gwarancje, ale nikt inny nie stosuje twojego podejścia do starych wersji.

8

Z ciekawostek - właśnie wczoraj przypomniał mi się ten wątek.
Akurat odpalałem jakiś zakurzony projekt, który leżał sobie kilka lat nie ruszany,
nie ma on teraz sensu i nie ma nawet po co odpalać... ale chciałem zobaczyć jak coś jest zrobione i przejechać się po testach.
Ale bym sie wkurzył jakby się okazało, że nie mogę zbudować, bo któraś z wielu bibliotek nie jest już dostępna w starej wersji i nie moge sobie przedebugować czegoś tylko dlatego, że ktoś oszczędza bajty na maven central.

Z drugiej strony:
zajęło mi 20 minut podbicie bibliotek do nowych wersji i w sumie tylko jeden mało istotny kawałek kodu musiałem wywalić, bo trzeba by było przerabiać (przez zmiany w api). Ale to akurat jest specyfika ekosystemu Javy - . W JS, Haskellu, Scali mała zmiana jakiejś wersji zwykle oznacza bolesne migracje.

7
somekind napisał(a):
jarekr000000 napisał(a):

OP pisał, że korzysta z semantic versioning. Wersje 0.x.y w semantic versioning to nie jest żaden prerelease. To zwykły release - z tym tylko, że ostrzega, że API może się zmienić w przyszłych wersjach, nic nie mówi o bezpieczeństwie/stabilności wersji biblioteki.
Prelease w semver oznacza się dodając zarostek -alpha (np. 1.1.1-alpha) lub inny podobny.

No OP tak pisał, ale też zostało to obalone, więc w ogóle nie rozważam tego w ten sposób. Wersje < 1.0.0 uważam za bezużyteczny brudnopis, jeśli tak nie jest, to w ogóle nie widzę sensu w ankiecie z tego wątku.

What? Wersje <1.0.0 oznaczają tylko, że API może się jeszcze zmienić, a nie, że to jest "bezużyteczny brudnopis". Jeśli to jest "bezużyteczny brudnopis" to po prostu tego nie publikujesz wcale.

0
Wibowit napisał(a):

ty. no chyba, że chciałeś się pochwalić, że usuwasz, a nie że inni mają usuwać. nie wiadomo o co ci chodzi. masz jakieś tam koszty i gwarancje, ale nikt inny nie stosuje twojego podejścia do starych wersji.

To jest totalne przeinaczanie moich słów. Nigdzie nie napisałem, że należy. Napisałem, że można - jeśli są ku temu powody, jeśli się o tym poinformuje, i da czas na użytkownikom na migrację. Nie kazałem nikomu tak postępować, ani nawet niespecjalnie przekonywałem do tego - po prostu wyraziłem swoją opinię w temacie.

Tradycyjnie polecam czytanie ze zrozumieniem, i odpisywanie na to, co zostało napisane, a nie to, co się sobie dopowiedziało do czyichś wypowiedzi.

6

@somekind: odnośnie nie napisałem, że należy - kwestia interpretacji, ale dla mnie poniższe fragmenty oznaczają jednoznacznie, że zalecasz/popierasz kasowanie starszych wersji. Podejrzewam, że 95% ludzi czytających Twoje wypowiedzi również oceni (a sądząc po tym, co piszą w wątku - tak właśnie to odbierają), że uważasz, iż stare wersje powinno się wywalić, gdy nie mają supportu i są nieaktualne. I żeby była jasność - nie chce się teraz kłócić o to, czy to dobre podejście czy nie, ale pokazać, że trochę się gubisz w zeznaniach: najpierw wiele razy wypowiadasz się w sposób popierający wywalanie, a potem piszesz że tak nie mówiłeś. OK - nie napisałeś wprost, że trzeba stare wersje wywalać, ale całokształt Twoich wypowiedzi jest ewidentnie za takim rozwiązaniem.

  • Ja bym wypieprzył, co najwyżej dał ludziom miesiąc - dwa na migrację.
  • stare wersje mogą być uboższe funkcjonalnie i zawierać błędy, nie widzę sensu w trzymaniu i supportowaniu ich.
  • A po co je trzymać, skoro są niewspierane?
  • Ja po prostu uważam, że trzymanie historii śmieci nie ma sensu.
  • najpierw robi się deprecated, a po jakimś czasie usuwa.

1 użytkowników online, w tym zalogowanych: 0, gości: 1