Riddle napisał(a):
A jak na zawsze, to jak wyjaśnić to ze PhpUnit i Laravel nie zachowały tych wersji?
To że ktoś inny zrobił źle to nie powód żeby samemu robić źle. Ale czemu autorzy frameworków PHP zrobili totalnie naodwrót niż robi się w świecie Javy. Nie wiem. Może trzeba by ich spytać. IMHO zrobili głupio
Riddle napisał(a):
Nie chcę usuwać wszystko starych wersji, a jedynie tylko tych przed
1.0.0.
sprawdziłem jeden z naszych mikroserwisów i w zależnościach mamy kilka bibliotek o głównej wersji = 0, dla przykładu:
Na jak długo? Bo raczej nie na zawsze?
A czemu nie na zawsze? W czym jest problem?
Przecież pisałem już wcześniej - paczka ZIP z kilkunastoma plikami tekstowymi z kodem to kilkadziesiąt/kilkaset KB, więc praktycznie zerowe miejsce na serwerze. Więc - co jest powodem, że tak panicznie się boisz pozostawienia tego?
A jak na zawsze, to jak wyjaśnić to ze PhpUnit i Laravel nie zachowały tych wersji?
Ale to jest ich sprawa. Argument skoro sąsiad zdradza/bije żonę, to ja też mogę jest z założenia inwalidą.
Zresztą - skoro chcesz się tak wzorcować na większych od siebie, to mam kilka inspiracji wartych rozważenia:
cerrato napisał(a):
Na jak długo? Bo raczej nie na zawsze?
A czemu nie na zawsze? W czym jest problem?
Przecież pisałem już wcześniej - paczka ZIP z kilkunastoma plikami tekstowymi z kodem to kilkadziesiąt/kilkaset KB, więc praktycznie zerowe miejsce na serwerze. Więc - co jest powodem, że tak panicznie się boisz pozostawienia tego?
Pytanie się sprowadza do tego, czy wersje 0.x.x powinny być publiczne czy nie.
Czy gdybym ich nie upublicznił wcześniej, i zadałbym pytanie "Mam wersję 1.0, czy powinienem upublicznić również wersje 0.x.x", to czy dostałbym 20 głosów na "tak"? Prawodpodobnie nie, nikomu by nie były potrzebne.
Ale uzyskaj ten sam efekt, od innej strony czyli: "Mając wersje 0.x.x oraz 1.0.0 czy powinienem usunąć starsze tagi?" i nagle jest 20 głosów zupełnie w inną stronę.
Efekt jest dokładnie taki sam: Czy jeśli ściągasz projekt w wersji 1.0.0, to chcesz żeby były publiczne również 0.x.x? Probably not.
Zresztą - skoro chcesz się tak wzorcować na większych od siebie, to mam kilka inspiracji wartych rozważenia:
- PHP wersja 6.0.1
- Slackware linux: przeskok z wersji 4 na 7
- Perl v.6 (Raku)
- IPv5
- Node.js i wersje 1-3
- DirectX w wersji 4
- J2SE w wersjach 2 do 4
Ale nie kumam o co chodzi z nimi?
Czy gdybym ich nie upublicznił wcześniej, i zadałbym pytanie
OK, ale upubliczniłeś. Czyli może ktoś z tego korzysta, może jest to część jakiegoś większego pakietu/aplikacji. Wiadomo, nie jest to jakaś wiodąca i bardzo popularna biblioteka, ale mimo wszystko - poszło to w świat i ktoś może z tego korzystać. Dlatego (moim zdaniem) w dobrym tonie jest zostawienie dostępnych tych wersji, które już zostały opublikowane i z których ludziska mogą realnie korzystać.
nagle jest 20 głosów zupełnie w inną stronę.
No to zobacz - skoro wszyscy głosujący mówią, żebyś to zostawił, to nie jest to jakaś moja (albo @KamilAdam) zachcianka.
I teraz ciekawa sprawa - dostałeś wynik, który jest nie po Twojej myśli. I co zrobisz - wedle swojego uznania (tylko w takim razie - po cholerę jest/był ten wątek?) czy posłuchasz vox populi?
Ale nie kumam o co chodzi z nimi?
To taka mała złośliwość :P
Skoro podajesz jako przykład Laravela czy phpUnit i ich sposób numeracji, to ja pokazałem kilka projektów z dziurami w numeracji/bez zachowanej ciągłości. Więc może idźmy za ciosem i po wersji 0.9.7 dajmy od razy 3.2.8? :P A tak nieco poważniej - chciałem jedynie pokazać, że argument "bo ktos tak zrobił to jest to dobre" jest zupełnie z czapy. Zresztą - Ty dajesz przykłady z PHP, a @KamilAdam dał kontrprzykłady z innego ekosystemu, gdzie zachowano się odmiennie. Więc nawet to nie ma sensu, nie da się powiedzieć, że wszyscy duzi gracze zachowują się w określony sposób.
Riddle napisał(a):
Pytanie się sprowadza do tego, czy wersje
0.x.xpowinny być publiczne czy nie.Czy gdybym ich nie upublicznił wcześniej, i zadałbym pytanie "Mam wersję 1.0, czy powinienem upublicznić również wersje 0.x.x", to czy dostałbym 20 głosów na "tak"? Prawodpodobnie nie, nikomu by nie były potrzebne.
Czy dobrze rozumiem, że po tym usunięciu starych wersji to potencjalnie przestaną działać projekty, które w zależnościach mają tą konkretną wersję? Jeśli już ktoś korzysta z biblioteki w jakiejś wersji to ma prawo nadal z niej korzystać, a nie być zmuszanym do upgrade'u, bo jest kolejny major.
Patrzysz na sprawę bardzo jednowymiarowo - "w jednym i drugim wypadku 0.x.y nie będzie dostępne". Tymczasem większość dyskutantów zwraca tutaj uwagę na inny wymiar - w przypadku "mam 1.0.0, czy upublicznić 0.x.y?" nie masz żadnych istniejących użytkowników, a więc i żadnych oczekiwań, względem 0.x.y. Z kolei w przypadku "wydałem 1.0.0, czy mam usunąć 0.x.y?" masz już istniejących użytkowników, którzy oczekują, że biblioteka będzie dalej dostępna - może i nierozwijana i niewspierana, ale mimo wszystko w dalszym ciągu dostępna.
Gdybym miał silić się na analogię, to trochę tak, jak debatować "wybudować samą drogę?" oraz "mamy stację kolejową, poprowadziliśmy drogę, czy zlikwidować kolej?". Niby rezultat jest taki sam - da się w to miejsce dojechać tylko samochodem. Ale o ile w pierwszym wypadku wszyscy wsiądą w samochody, bo nigdy nie mieli alternatywy - o tyle w drugim, będzie grupa ludzi, która bardzo lubiła komunikację pociągiem i będzie z likwidacji bardzo niezadowolona.
Może inaczej - jakie widzisz korzyści w usuwaniu tego? Musisz dopłacać za utrzymywanie tych wersji? Jeśli mają jakieś podatności to usuń, ale normalnie nie ma nawet takiej możliwości.
W dobie web aplikacji nie ma to już takiego znaczenia ale w aplikacjach desktopowych po zrobieniu releasa, fixowało się wersje paczek tak żeby można było przekompilować w każdej chwili archiwalną wersję aplikacji i dostać dokładnie takie same binarki. Takie nagłe usuwanie starych wersji tylko może komuś utrudnić życie bo wtedy nagle w tej sytuacji trzeba by było upgrade'ować którąś paczkę co nie musi być w pełni bezpieczne i może utrudnić na przykład zreprodukowanie buga który user zgłosił w starym, ale nadal utrzymywanym sofcie.
cerrato napisał(a):
Czy gdybym ich nie upublicznił wcześniej, i zadałbym pytanie
OK, ale upubliczniłeś. Czyli może ktoś z tego korzysta, może jest to część jakiegoś większego pakietu/aplikacji. Wiadomo, nie jest to jakaś wiodąca i bardzo popularna biblioteka, ale mimo wszystko - poszło to w świat i ktoś może z tego korzystać. Dlatego (moim zdaniem) w dobrym tonie jest zostawienie dostępnych tych wersji, które już zostały opublikowane i z których ludziska mogą realnie korzystać.
No, czyli jedynym argumentem za tym, żeby je zostawić jest to, że ktoś może z nich korzystać.
Argumentem przeciw mogłoby być:
0 i 1.Nie opieram się za żadną opcją, nie mam ochoty się z nikim kłucić. Próbuję tylko zilustrować że wybór nie jest znowu taki czarno biały.
nagle jest 20 głosów zupełnie w inną stronę.
No to zobacz - skoro wszyscy głosujący mówią, żebyś to zostawił, to nie jest to jakaś moja (albo @KamilAdam) zachcianka.
I teraz ciekawa sprawa - dostałeś wynik, który jest nie po Twojej myśli. I co zrobisz - wedle swojego uznania (tylko w takim razie - po cholerę jest/był ten wątek?) czy posłuchaszvox populi?
Pytanie zadałem żeby pogodzić różny wynik (tego czy mają być tagi 0.x.x czy nie) wychodząc z punktu w którym one już były publiczne czy też nie.
To taka mała złośliwość :P Skoro podajesz jako przykład Laravela czy phpUnit i ich sposób numeracji, to ja pokazałem kilka projektów z dziurami w numeracji/bez zachowanej ciągłości. Więc może idźmy za ciosem i po wersji 0.9.7 dajmy od razy 3.2.8? :P A tak nieco poważniej - chciałem jedynie pokazać, że argument "bo ktos tak zrobił to jest to dobre" jest zupełnie z czapy. Zresztą - Ty dajesz przykłady z PHP, a @KamilAdam dał kontrprzykłady z innego ekosystemu, gdzie zachowano się odmiennie. Więc nawet to nie ma sensu, nie da się powiedzieć, że wszyscy duzi gracze zachowują się w określony sposób.
No to w takim razie pojawia się pytanie, jak długo ta wersja 0.x.x. ma być publiczna? Jak wydam T-Regx 2.0, 3.0, etc.? Czy jak będzie dostępne 13.0, to 0.x nadal ma być publiczne?
PS: Zaczynam się zastanawiać że to głosy "Zostawić na zawsze" nie wynikają wcale z podejścia "Jak zrobić żeby było dobrze", tylko z potencjalnego strachu przed tym że komuś projekt się nagle wywali.
Riddle napisał(a):
Pytam, bo np taki phpunit albo laravel, to nawet wersji 3.x.x nie trzymają.
jedynym powodem dlaczego phpunit nie ma wersji <3.7.0 na packagist jest taki że packagist wcześniej nie istniał. Zarówno packagist jak i wersja 3.7.0 powstała w 2012 roku. Po prostu nie przenieśli tam starych paczek, ale nikt nigdy niczego nie usunął. To samo w przypadku laravela
Riddle napisał(a):
No to w takim razie pojawia się pytanie, jak długo ta wersja
0.x.x.ma być publiczna? Jak wydam T-Regx 2.0, 3.0, etc.? Czy jak będzie dostępne 13.0, to0.xnadal ma być publiczne?
oczywiście
Riddle napisał(a):
PS: Zaczynam się zastanawiać że to głosy "Zostawić na zawsze" nie wynikają wcale z podejścia "Jak zrobić żeby było dobrze", tylko z potencjalnego strachu przed tym że komuś projekt się nagle wywali.
Nie ze strachu, tylko ze zwykłej życzliwości i rozsądku.
Przecież to nie ja miałbym problem po usunięciu starej paczki, czemu miałbym się tego bać.
Riddle napisał(a):
No, czyli jedynym argumentem za tym, żeby je zostawić jest to, że ktoś może z nich korzystać.
... W - T - F
No tak - jedynym celem publikowania paczek jest to żeby ktoś mógł z nich korzystać. Chyba że czegoś nie wiem.
Czy watek zmienił tytuł?
Jeżeli tak (a takie mam wrażenie ) to aktualna ankieta nie ma sensu.
Ja bym wypieprzył, co najwyżej dał ludziom miesiąc - dwa na migrację.
Jak zgaduję, stare wersje mogą być uboższe funkcjonalnie i zawierać błędy, nie widzę sensu w trzymaniu i supportowaniu ich.
Nie rozumiem w jaki sposób trzymanie wersji == supportowanie.
Były releasy publiczne to po co się z nimi kryć, usuwać?
Wystarczy napisać które wersję są wspierane.
Np
N+1 - rozwojowa
N - bieżąca
N-1 - bugfixy
opiszon napisał(a):
Były releasy publiczne to po co się z nimi kryć, usuwać?
A po co je trzymać, skoro są niewspierane?
somekind napisał(a):
Ja bym wypieprzył, co najwyżej dał ludziom miesiąc - dwa na migrację.
Jak zgaduję, stare wersje mogą być uboższe funkcjonalnie i zawierać błędy, nie widzę sensu w trzymaniu i supportowaniu ich.
Tzn ja temat traktuję ogólnie, nie mówiąc konkretnie o paczce riddla - tutaj nie ma wątpliwości, skoro jest praktycznie nieużywana to niech sobie robi co chce (i tak zamierza), nikt nie będzie płakał.
Natomiast w przypadku poważnych paczek raczej ma sens trzymania starych wersji - często można użyć tylko starej paczki bo musimy się trzymać z jakiegoś powodu jakiejś starej wersji frameworka, języka czy innej paczki i ze względu na wzajemne zależności tylko taka konfiguracja może działać na ten moment.
Często też stare paczki nie tylko są upublicznione ale też wspierane - przykładowo windows app sdk jest obecnie w wersji 1.1, 1.2-preview a nadal obok są robione releasy do wersji 0.8 która jest wspierana i dostaje bugfixy.
Też w przypadku regresji user może przetestować starszą wersję i dać za przykład jak to powinno działać i kiedy przestało.
Chyba że uważasz że w ogóle repozytoria paczek nie mają sensu i w sumie to można by trzymać tylko ostatnią wersję każdej paczki? Nigdy jak rozumiem nie używałeś żadnej paczki w wersji innej niż aktualna? Też na pewno nie ograniczasz wersji tylko lecisz na żywca i każdy build robisz z najnowszymi paczkami bo co może pójść źle? Na pewno wszystko zadziała i nie zmarnuje ci to czasu.
Jak już wspomniałem wyżej - śmieszne jest że za przykład podał laravel i phpunit że usunęli stare paczki a prawda jest taka że nigdy ich nie usunęli tylko repozytorium powstało później. Tych paczek po prostu nigdy nie było.
obscurity napisał(a):
Jak już wspomniałem wyżej - śmieszne jest że za przykład podał laravel i phpunit że usunęli stare paczki a prawda jest taka że nigdy ich nie usunęli tylko repozytorium powstało później. Tych paczek po prostu nigdy nie było.
No to równie dobrze mógłbym zrobić nowe repo z nową paczką, nazwałbym ją T-Regx2 i w niej byłyby tylko wersje 1.0.0 (nie dodałbym żadnych wcześniejszych), i też można by powiedzieć "W tej paczce wersji 0.x.x nigdy nie było", i jest ten sam temat.
I co, wtedy to już jest spoko że tych wersji 0.x.x nie ma?
Riddle napisał(a):
No to równie dobrze mógłbym zrobić nowe repo z nową paczką, nazwałbym ją
T-Regx2i w niej byłyby tylko wersje1.0.0(nie dodałbym żadnych wcześniejszych), i też można by powiedzieć "W tej paczce wersji0.x.xnigdy nie było", i jest ten sam temat.I co, wtedy to już jest spoko że tych wersji
0.x.xnie ma?
No będą tylko że w tym starym repo. Nie jest spoko bo wtedy utrudniasz upgrade - ludki sobie używają starej wersji i myślą że nie ma nowszej bo nic im nie pokazuje w opcji update'u. Nie "równie dobrze" bo ja nie mówię o twoim repo tylko repozytorium paczek. Packagist nie istniał wcześniej. Wcześniejsze wersje phpunit można znaleźc w archiwum pear
obscurity napisał(a):
Chyba że uważasz że w ogóle repozytoria paczek nie mają sensu i w sumie to można by trzymać tylko ostatnią wersję każdej paczki?
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.
Nigdy jak rozumiem nie używałeś żadnej paczki w wersji innej niż aktualna?
A czy Ty używasz tylko niewspierane paczek pełnych błędów i dziur bezpieczeństwa?
Też na pewno nie ograniczasz wersji tylko lecisz na żywca i każdy build robisz z najnowszymi paczkami bo co może pójść źle? Na pewno wszystko zadziała i nie zmarnuje ci to czasu.
Major nie idzie z automatu, bo z definicji działał nie będzie, ale reszta już najczęściej tak.
Jak już wspomniałem wyżej - śmieszne jest że za przykład podał laravel i phpunit że usunęli stare paczki a prawda jest taka że nigdy ich nie usunęli tylko repozytorium powstało później. Tych paczek po prostu nigdy nie było.
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.
somekind napisał(a):
opiszon napisał(a):
Były releasy publiczne to po co się z nimi kryć, usuwać?
A po co je trzymać, skoro są niewspierane?
bo są potrzebne do zbudowania apek korzystających z niewspieranych wersji bibliotek.
jeśli mam jakąś apkę, która działa od 5 lat nieruszana i potrzebuję zrobić w niej małą zmianę to do zbudowania jej od nowa mogę potrzebować ściągnąć wszystkie zależności od nowa (bo np. mam nowego kompa i nie mam jeszcze cache na dysku). jeśli te zależności będą usunięte u źródła to co mam wtedy zrobić? upgrade całej apki, żeby móc coś zmienić? w ogóle to byłoby koszmarne pałowanie się. dla przykładu używam libabc w wersji 2.x, po 5 latach wspierane są wersje tylko 5.x w górę, więc by zrobić małą poprawkę do apki muszę zrobić najpierw migrację libabc z 2.x do 5.x w jednym kroku (bo nic mi się nie zbuduje przed migracją do 5.x) i dopiero wtedy robić docelowe usprawnienie.
Wibowit napisał(a):
somekind napisał(a):
opiszon napisał(a):
Były releasy publiczne to po co się z nimi kryć, usuwać?
A po co je trzymać, skoro są niewspierane?
bo są potrzebne do zbudowania apek korzystających z niewspieranych wersji bibliotek.
jeśli mam jakąś apkę, która działa od 5 lat nieruszana i potrzebuję zrobić w niej małą zmianę to do zbudowania jej od nowa mogę potrzebować ściągnąć wszystkie zależności od nowa (bo np. mam nowego kompa i nie mam jeszcze cache na dysku). jeśli te zależności będą usunięte u źródła to co mam wtedy zrobić? upgrade całej apki, żeby móc coś zmienić? w ogóle to byłoby koszmarne pałowanie się. dla przykładu używam libabc w wersji 2.x, po 5 latach wspierane są wersje tylko 5.x w górę, więc by zrobić małą poprawkę do apki muszę zrobić najpierw migrację libabc z 2.x do 5.x w jednym kroku (bo nic mi się nie zbuduje przed migracją do 5.x) i dopiero wtedy robić docelowe usprawnienie.
To wszystko co opisujesz ma bardzo duży sens, bo nawet jeśli jakiś React czy inny Django ma wersję 13.0, a za rok będzie już 17.0, to wersje 2.0 i 3.0 powinny działać.
Ale dyskusja nie tyczy sie "starych wersji w ogóle" (bo wtedy sprawa jest jasna, że należy je zostawić), a tylko wersji 0.x., zanim została wydana faktyczna wersja 1.0, którą można uznać za sensowną bibliotekę/zależność.
somekind napisał(a):
obscurity napisał(a):
Jak już wspomniałem wyżej - śmieszne jest że za przykład podał laravel i phpunit że usunęli stare paczki a prawda jest taka że nigdy ich nie usunęli tylko repozytorium powstało później. Tych paczek po prostu nigdy nie było.
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.
Co w tym dziwnego?
Abstrahujac juz od tej phpowej biblioteki krzak (z calym szacunkiem). Jezeli ktos cos udostepnia to zwyczajnie glupio jest potem to zabierac (jest nawet takie przyslowie kto daje i zabiera...). Wersja jest niewspierana? Okej zrob deprecated, daj mi 100 warningow do buildu czy cokolwiek. Niefajnie jest natomiast kiedy w poniedzialek rano chce sobie dokonczyc taska, a tu sie okazuje ze musze upgradowac biblioteke, a po drodze jeszcze x rzeczy sie skaszanilo. Jeszcze bardziej niefajne jest jesli masz jakies wewnetrzne skrypty odpalane raz na pare miesiecy i okazuje sie, ze musisz je poprawiac, a kazde zajrzenie do ich wnetrza powoduje wymioty.
Wedlug mnie ponizszy cytat z dyskusji rozwiazuje caly watek:
obscurity napisał(a):
Riddle napisał(a):
Riddle napisał(a):
PS: Zaczynam się zastanawiać że to głosy "Zostawić na zawsze" nie wynikają wcale z podejścia "Jak zrobić żeby było dobrze", tylko z potencjalnego strachu przed tym że komuś projekt się nagle wywali.
Nie ze strachu, tylko ze zwykłej życzliwości i rozsądku.
Przecież to nie ja miałbym problem po usunięciu starej paczki, czemu miałbym się tego bać.
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.
Rozumiem że usuwasz go nie tylko z repozytorium ale czyścisz też historię gita.
W ogóle w normalnym świecie, poza php nie ma tematu. Raz opublikowanych paczek nie da się usunąć w żadnym szanującym się repozytorium paczek. Nie ma dylematu
Riddle napisał(a):
Ale dyskusja nie tyczy sie "starych wersji w ogóle" (bo wtedy sprawa jest jasna, że należy je zostawić), a tylko wersji
0.x., zanim została wydana faktyczna wersja 1.0, którą można uznać za sensowną bibliotekę/zależność.
w mavenowych repozytoriach konwencja jest inna. jeśli chcesz pokazać, że dana wersja nie jest oficjalna to dopisujesz do wersji końcówkę "-SNAPSHOT" (a więc np. masz wersję 2.3.4-SNAPSHOT). możliwości są więc takie:
dzięki takiemu podejściu użytkownicy danej wersji biblioteki od razu wiedzą czego się spodziewać. nie muszą się martwić tym czy autor biblioteki kiedyś nabierze ochoty na usuwanie swoich wytworów.
@Riddle: jeśli nie ostrzegałeś od początku swoich użytkowników, że będziesz usuwał wersje < 1.0.0, to usuwając je wypinasz się na swoich użytkowników.
Odpowiadam tylko na Twoje pytanie. Zapytałeś: "Skoro opublikowales wersje 0.x. to czym sie ona rozni od 1.0+?", więc odesłałem Cię do SemVer, i teraz już masz odpowiedź na swoje pytanie, czym ona się różni ;) Jeśli masz inne pytanie, to napisz post poniżej, komentarze nie są od tego.
Nie wiem czy zrobiles to specjalnie czy moze moje intencje byly niejasne, ale to pytanie bylo w gruncie rzeczy retoryczne. Watek nie tyczy sie tego, ze "wykryto critical vulna w mojej libce 0.x czy powinienem go fixowac niszczac kompatybilnosc wsteczna". Jezeli wydales wersje 0.x to owszem, nikomu niczego nie obiecujesz, ale tez nie widze powodu zeby cos usuwac "bo tak". Taka zwykla, ludzka uprzejmosc. Jezeli sasiadka zapuka po szczypte soli masz pelne prawo powiedziec jej, ze nie pozyczysz i zeby poszla sobie do sklepu. Pozostaje sie zastanowic czy kwestie prawne (czy w tym przypadku standardy wersjonowania) to wszystko co nas interesuje i to juz pozostawiam Tobie do oceny.
Seken napisał(a):
Nie wiem czy zrobiles to specjalnie czy moze moje intencje byly niejasne, ale to pytanie bylo w gruncie rzeczy retoryczne. Watek nie tyczy sie tego, ze "wykryto critical vulna w mojej libce 0.x czy powinienem go fixowac niszczac kompatybilnosc wsteczna". Jezeli wydales wersje 0.x to owszem, nikomu niczego nie obiecujesz, ale tez nie widze powodu zeby cos usuwac "bo tak". Taka zwykla, ludzka uprzejmosc. Jezeli sasiadka zapuka po szczypte soli masz pelne prawo powiedziec jej, ze nie pozyczysz i zeby poszla sobie do sklepu. Pozostaje sie zastanowic czy kwestie prawne (czy w tym przypadku standardy wersjonowania) to wszystko co nas interesuje i to juz pozostawiam Tobie do oceny.
No bardzo ładnie, tylko że gdybym te wersje 0.x.x trzymał u siebie lokalnie, i wydał 1.0.0, to nikt by nie przyszedłi i nie powiedział "Wiesz co, powinieneś też wydać te wersje 0.x.x które masz". Więc wersje 0.x.x powinny być publicznie dostępne, czy nie?
Ten wątek jest podzielony, widzę że większość ludzi ma przekonanie:
Nie widzicie na prawdę że te odpowiedzi są niespójne?
Może ktoś już to napisał (bo to się aż narzuca), ale jeśli ktoś ma w projekcie starą wersję i jej używa i nie chce aktualizować do nowej wersji, bo by musiał przepisywać istniejący kod, a nie chce tego robić?
Czyli świadomie nie chce apdejtu i chce korzystać ze starej niewspieranej wersji, bo nie chce ponosić kosztu czasowego na przerabianie już napisanego kodu (zakładając, że API biblioteki czy sposób działania by się zmieniły w jakiś drastyczny sposób).
Nie widzicie na prawdę że te odpowiedzi są niespójne?
Jak niby niespójne? Jeśli opublikowałeś wersję, to już nigdy jej nie usuwasz, jeśli nie opublikowałeś, to nie musisz nigdy jej publikować. Proste jak drut. Chyba nie da się tego bardziej oczywiście przedstawić.
Już pomijam, że niektóre repozytoria paczek nie pozwalają na edycję/usunięcie opublikowanych wydań.
hauleth napisał(a):
Nie widzicie na prawdę że te odpowiedzi są niespójne?
Jak niby niespójne? Jeśli opublikowałeś wersję, to już nigdy jej nie usuwasz, jeśli nie opublikowałeś, to nie musisz nigdy jej publikować. Proste jak drut. Chyba nie da się tego bardziej oczywiście przedstawić.
Już pomijam, że niektóre repozytoria paczek nie pozwalają na edycję/usunięcie opublikowanych wydań.
True, ale nie odpowiada to na pytanie: "Czy biblioteki powinny mieć publiczne wersje 0.x.x?".
LukeJL napisał(a):
Może ktoś już to napisał (bo to się aż narzuca), ale jeśli ktoś ma w projekcie starą wersję i jej używa i nie chce aktualizować do nowej wersji, bo by musiał przepisywać istniejący kod, a nie chce tego robić?
Czyli świadomie nie chce apdejtu i chce korzystać ze starej niewspieranej wersji, bo nie chce ponosić kosztu czasowego na przerabianie już napisanego kodu (zakładając, że API biblioteki czy sposób działania by się zmieniły w jakiś drastyczny sposób).
Tylko podając taki argument, równie dobrze mógłbyś powiedzieć że nie można robić push-force'ów na mastera albo developa. Bo ktoś mógł w swojej paczce wpisać "dev-master", i jak zrobisz robiąc push-force, temu komuś się zepsuje jego projekt nie updateowany wcześniej.
Nie, żeby coś, ale z python.org można ściągnąć jeszcze Pythona 2.0.1 (z 2001 roku):
https://www.python.org/downloads/
chociaż wcześniejszych wersji już nie ma na tej liście.