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

Wszystko zależy jak bardzo niestabilne są twoje wersje 0.x.y. Znam co najmniej dwie biblioteki które były już bardzo stabilne w wersji 0.x.y i jednej nawet używałem produkcyjne czyli vavr

KamilAdam napisał(a):

Wszystko zależy jak bardzo niestabilne są twoje wersje 0.x.y. Znam co najmniej dwie biblioteki które były już bardzo stabilne w wersji 0.x.y i jednej nawet używałem produkcyjne czyli vavr

Co masz na myśli mówiąc "stabilne"?

Nie wprowadzające breaking-changes, czy takie które się "nie wywalają"?

Moja biblioteka jest używana w trzech produkcyjnych projektach u mnie w pracy, + na 4programmers, + jeszcze w kilku innych projektach które widzę na githubie, więc pod tym względem raczej jest "stabilna".

Co do "stabilności" wprowadzania breaking changes, to stosuję sem.ver, więc kiedy wprowadzam breaking change, to podbijam odpowiednią wersję.

Riddle napisał(a):

Nie wprowadzające breaking-changes, czy takie które się "nie wywalają"?

Takie że nie jest strach brać do produkcyjnego projektu. Więc w zasadzie oba. Chyba nie ma nic gorszego niż jak się weźmie jakąś bibliotekę a tam co chwila totalne breaking changes i żeby upgradnąć bibliotekę trzeba przepisać cały kod

Riddle napisał(a):

Za kilka miesięcy wydam wersję 1.0 swojej biblioteki, i zastanawiam się co zrobić z wersjami 0.x.x.? Aktualnie jest 0.37.0, i około 67 release'ów wcześniej są inne.

Pytam, bo np taki phpunit albo laravel, to nawet wersji 3.x.x nie trzymają.

w jakim sensie trzymają? Samo trzymanie przecież nie wymaga zachodu, wystarczy, że jest sobie na Githubie. Natomiast utrzymywanie/wspieranie poprzednich wersji to może być problem.

LukeJL napisał(a):

Riddle napisał(a):

Za kilka miesięcy wydam wersję 1.0 swojej biblioteki, i zastanawiam się co zrobić z wersjami 0.x.x.? Aktualnie jest 0.37.0, i około 67 release'ów wcześniej są inne.

Pytam, bo np taki phpunit albo laravel, to nawet wersji 3.x.x nie trzymają.

w jakim sensie trzymają? Samo trzymanie przecież nie wymaga zachodu, wystarczy, że jest sobie na Githubie. Natomiast utrzymywanie/wspieranie poprzednich wersji to może być problem.

Zachodu nie wymaga.

Ale to znaczy że jak ktoś sobie otworzy packagista albo composer.json, to IDE mu podpowie że są takie dostępne, i ktoś będzie w stanie jest zainstalować, co może nie być idealne.

Riddle napisał(a):

Ale to znaczy że jak ktoś sobie otworzy packagista albo composer.json, to IDE mu podpowie że są takie dostępne, i ktoś będzie w stanie jest zainstalować, co może nie być idealne.

No ale chyba jest tak że średnio rozgarnięty programista stara się wybierać wersje najświeższe?

Dla porównania Spring w repo maven jest od wersji 1.0.0 z Dec 23, 2005. Jest nawet oznaczenie 15 vulnerabilities co raczej odradza używanie, ale wersja dalej jest

KamilAdam napisał(a):

Riddle napisał(a):

Ale to znaczy że jak ktoś sobie otworzy packagista albo composer.json, to IDE mu podpowie że są takie dostępne, i ktoś będzie w stanie jest zainstalować, co może nie być idealne.

No ale chyba jest tak że średnio rozgarnięty programista stara się wybierać wersje najświeższe?

Dla porównania Spring w repo maven jest od wersji 1.0.0 z Dec 23, 2005. Jest nawet oznaczenie 15 vulnerabilities co raczej odradza używanie, ale wersja dalej jest

No ale nie ma wersji 0.x.x, więc musiały zostać usunięte.

Riddle napisał(a):

No ale nie ma wersji 0.x.x, więc musiały zostać usunięte.

Czytam że pierwszą produkcyjną wersją springa było 1.0 więc wcześniejsze mogły nie być nawet umieszczone w mevenowym repo

UPDATE tak jak myślałem. Nie da się usunąć wersje z central repo maven:

Can't be done. It's A Rule. But if you want to try, contact the Sonatype people who support oss.sonatype.org. So you generally push a new, higher, version with the fix, and tell everyone to use it.

https://stackoverflow.com/questions/9789611/removing-an-artifact-from-maven-central

KamilAdam napisał(a):

Riddle napisał(a):

No ale nie ma wersji 0.x.x, więc musiały zostać usunięte.

Czytam że pierwszą produkcyjną wersją springa było 1.0 więc wcześniejsze mogły nie być nawet umieszczone w mevenowym repo

W mavenowym może nie, ale w kontroli wersji pewnie mieli tagi 0.x.x. Tak czy tak, spring nie ma takich wersji, to czemu moja libka miałaby mieć.

No to usuwaj. W czym problem. Najwyżej komuś coś się nie skompiluje

KamilAdam napisał(a):

No to usuwaj. W czym problem. Najwyżej komuś coś się nie skompiluje

Czemu miałoby?

No jak ktoś ma w swoim projekcie podpiętą wersję 0.x.y a ty ją usuniesz to będzie dalej działać?

KamilAdam napisał(a):

No jak ktoś ma w swoim projekcie podpiętą wersję 0.x.y a ty ją usuniesz to będzie dalej działać?

No więc zostaje opcja Poczekać kilka miesięcy/lat i usunąć.

Riddle napisał(a):

Ale to znaczy że jak ktoś sobie otworzy packagista albo composer.json, to IDE mu podpowie że są takie dostępne, i ktoś będzie w stanie jest zainstalować, co może nie być idealne.

Jeśli ktoś zainstaluje coś, co nie jest oficjalnie wspierane (możesz nawet w dokumentacji napisać, które wersje są wspierane), to jego problem.

Olbrzymia ilość solidnego oprogramowania jest w wersjach 0.x (a niezerowy >=1 numer główny nie gwarantuje jakości)

To w mim odczuciu się otworzyło z czasami opensource, być może za czasów "zamkniętych" modne było śrubowanie numeru wersji do 17.21 itd

ZrobieDobrze napisał(a):

To w mim odczuciu się otworzyło z czasami opensource, być może za czasów "zamkniętych" modne było śrubowanie numeru wersji do 17.21 itd

Legenda mówi że Oracle zostało wydane od razu w wersji 2.0 żeby sugerować że poprawiono już wszystkie bugi

Note that there was no v1 of Oracle Database, as co-founder Larry Ellison "knew no one would want to buy version 1"

Teraz to jest jakby wręcz odwrotna tendancja. Jak to biblioteka/język jets w wersji trzeciej? Aż trzech wersji potrzebowali żeby zrobić coś dobrze?!

jak ktoś sobie otworzy packagista albo composer.json, to IDE mu podpowie że są takie dostępne

No a nie lepiej zrobić "automagiczne zasysanie" wersji bieżącej, ale gdzieś na stronie projektu dać linki do możliwego pobrania wersji starszej? W sensie - composer mu wsadzi wersję bieżącą (co w 99% przypadków jest działaniem pożądanym), ale jeśli z jakiegoś powodu, zamiast 1.0.3.5 będzie potrzebował 0.7.1.9 to sobie może ręcznie tą wersję pobrać i podłączyć ręcznie do projektu.

Nie wiem, w czym problem. Podejrzewam, że ZIP z kodem biblioteki to kilkadziesiąt KB, więc trzymanie nawet 200 wersji na serwerze w niczym nie przeszkadza.

Pytanie jest inne - czy kod, który działa z wersją 0.x pójdzie jak podmienisz na wersję 1.x czy 2.x? Bo to chyba główna rzecz, która ma wpływ na decyzję. Ale tak czy siak - dałbym gdzieś na stronie projektu jakąś sekcję z możliwością pobrania wersji archiwalnych.

cerrato napisał(a):

Ale tak czy siak - dałbym gdzieś na stronie projektu jakąś sekcję z możliwością pobrania wersji archiwalnych.

No, tylko po co?

Spring ich nie ma, phpunit ich nie ma, laravel ich nie ma, ogromna ilość otwartego oprogramowania nie ma wersji archiwalnych.

Czytając z "Semantic Versioning":

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

Więc jeśli ktoś się przejmuje sem-ver, to i tak nie powinien używać wersji 0.x.x, jeśli dostępna jest 1.0.0+.

Riddle napisał(a):

Spring ich nie ma, (...), ogromna ilość otwartego oprogramowania nie ma wersji archiwalnych.

Ale proszę pana, pan teraz rozmija się z prawdą. Przecież pokazałem że spring ma wersje archiwalne 17 lat wstecz. A wynika to chociażby z tego że jak coś się opublikuje do centralnego repozytorium mavena to już usunąć tego nie można (poza szczególnymi przypadkami)

To że nie ma tam wersji 0.x.y wynika z tego że nigdy nie opublikowali wersji 0.x.y
Ale już taki vavr jak najbardziej jest w wersji 0.x.y https://mvnrepository.com/artifact/io.vavr/vavr

W Haskellu też nie wyrzucają starych paczek z centralnego repo. Relude jest od wersji 0.1.0. Podobnie free monad

KamilAdam napisał(a):

Riddle napisał(a):

Spring ich nie ma, (...), ogromna ilość otwartego oprogramowania nie ma wersji archiwalnych.

Ale proszę pana, pan teraz rozmija się z prawdą. Przecież pokazałem że spring ma wersje archiwalne 17 lat wstecz. A wynika to chociażby z tego że jak coś się opublikuje do centralnego repozytorium mavena to już usunąć tego nie można (poza szczególnymi przypadkami)

No dobra, ale co to właściwie znaczy, że spring ma tylko 1.0.0+ i nie ma 0.x.x? Czy ktoś od razu napisał stabilną wersję 1.0.0 i ją upublicznił? Czy może tworzył wcześniej wersje 0.x.x, tylko ich nie dodał do mavena?

Jeśli to pierwsze, to gratulacje dla springa. Jeśli to drugie, to czym się różni "nie dodanie wersji do mavena" od "usunięcia upulibcznionych tagów z githuba".

Poza tym, to nie wyjaśnia czemu phpunit, laravel i inne duże libki nie mają publicznych tagów 0.x.x.

Riddle napisał(a):

No dobra, ale co to właściwie znaczy, że spring ma tylko 1.0.0+ i nie ma 0.x.x? Czy ktoś od razu napisał stabilną wersję 1.0.0 i ją upublicznił? Czy może tworzył wcześniej wersje 0.x.x, tylko ich nie dodał do mavena?

Nie ważne co to znaczy :D Ważne jest to że jak dajesz ludziom jakąś wersję libki to potem tej libki się nie usuwa bo tworzysz ludziom problemy i wychodzisz na nieprofesjonalnego.

Mają sprint zaplanowany, przychodza w poniedziałek do pracy a teraz się okazuje że projekt się nie kompiluje bo @Riddle usunął wersję i zamiast sprintu trzeba robić szybki upgrade. Oczywiście jak mają lokalne cachowanie to im to zadziała. No ale ryzyko f'uck upu istnieje

Zależy to chyba od środowiska, bo przykładowo npm stara się trzymać wszystkie wersje paczek, które zostały w nim opublikowane i można znaleźć pierwsze wersje np Reacta, Angulara i sobie zainstalować

https://www.npmjs.com/package/react/v/0.0.1 (wydana 11 lat temu)
https://www.npmjs.com/package/@angular/core/v/0.0.0-0 (wydana 6 lat temu)

Czasami zdarzają się jedynie sytuacje, że przestają działać linki do starej dokumentacji :D, ale to już nie wina twórców npm'a.

No, tylko po co?
Spring ich nie ma, phpunit ich nie ma, laravel ich nie ma, ogromna ilość otwartego oprogramowania nie ma wersji archiwalnych.

OK, ale w czym jest problem?
Co się stanie, jak do jakiegoś archiwum wrzucisz wszystkie stare wersje?
A jeśli tak Cie to boli - to po co pytasz, co zrobić? Wywal to wszystko, zostaw tylko bieżącą i po temacie :P

KamilAdam napisał(a):

Riddle napisał(a):

No dobra, ale co to właściwie znaczy, że spring ma tylko 1.0.0+ i nie ma 0.x.x? Czy ktoś od razu napisał stabilną wersję 1.0.0 i ją upublicznił? Czy może tworzył wcześniej wersje 0.x.x, tylko ich nie dodał do mavena?

Nie ważne co to znaczy :D Ważne jest to że jak dajesz ludziom jakąś wersję libki to potem tej libki się nie usuwa bo tworzysz ludziom problemy i wychodzisz na nieprofesjonalnego.

Mają sprint zaplanowany, przychodza w poniedziałek do pracy a teraz się okazuje że projekt się nie kompiluje bo @Riddle usunął wersję i zamiast sprintu trzeba robić szybki upgrade. Oczywiście jak mają lokalne cachowanie to im to zadziała. No ale ryzyko f'uck upu istnieje

To mi to wygląda jak opcja w ankiecie Poczekać kilka miesięcy/lat i usunąć.

Czyli wrzucić 1.0.0, oznaczyć wszystkie 0.x.x jako abandoned, i za kilka miesięcy lub lat usunąć.

Jeśli ktoś trzyma libke pół roku która jest abandoned, to prędzej czy później się zdziwi żę jej nie ma.

Nie widzę powodu, dla którego miałbym usuwać starsze wersje libki czy programu. Jak ktoś chce, to niech używa - co mi szkodzi?

@Riddle: w korpo stare trupy potrafią żyć (jak zombie) po naście lat, więc jak chcesz mieć korpo-friendly bibliotekę to usuwanie starych wersji nie jest dobrym pomysłem.

ktoś tam może mówić o braku wsparcia, podatnościach i innych niby przekreślających starą wersję biblioteki wadach, ale prawda jest taka, że za siedmioma proksiakami, za siedmioma firewallami i za siedmioma przekierowaniami siedzi sobie niezliczona ilość starych trupów, które dalej działają i napędzają biznes.

Wibowit napisał(a):

@Riddle: w korpo stare trupy potrafią żyć (jak zombie) po naście lat, więc jak chcesz mieć korpo-friendly bibliotekę to usuwanie starych wersji nie jest dobrym pomysłem.

ktoś tam może mówić o braku wsparcia, podatnościach i innych niby przekreślających starą wersję biblioteki wadach, ale prawda jest taka, że za siedmioma proksiakami, za siedmioma firewallami i za siedmioma przekierowaniami siedzi sobie niezliczona ilość starych trupów, które dalej działają i napędzają biznes.

Nie chcę usuwać wszystko starych wersji, a jedynie tylko tych przed 1.0.0.

Nie chcę usuwać wszystko starych wersji, a jedynie tylko tych przed 1.0.0.

Jeżeli to były Twoje wersje testowe/prywatne, to wywal.
Jeśli udostępniłeś to społeczeństwu i wersje 0.x.x poszły w świat, to raczej powinieneś zostawić.

cerrato napisał(a):

Nie chcę usuwać wszystko starych wersji, a jedynie tylko tych przed 1.0.0.

Jeżeli to były Twoje wersje testowe/prywatne, to wywal.
Jeśli udostępniłeś to społeczeństwu i wersje 0.x.x poszły w świat, to raczej powinieneś zostawić.

Na jak długo? Bo raczej nie na zawsze?

A jak na zawsze, to jak wyjaśnić to ze PhpUnit i Laravel nie zachowały tych wersji?