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.
Dodatkowo, co może niektórych zaszokować, nawet oznaczenie wersji biblioteki jako 1.x.y , albo 2.x.y również nie oznacza, że nie ma ona dziur i jest bezpieczna.
Niemniej jednak wersja 1.0.0, to jest ewidentnie osiągnięcie jakiegoś etapu, na którym którym autor uznał, że jest to produkt według jakichś tam jego kryteriów gotowy do puszczenia w świat. (Co bynajmniej nie oznacza idealnego na wieki.)
Ten zestaw pytań świadczy o tym, że ewidentnie mylisz utrzymywanie projektu, z utrzymywanie ogólnodostępnej biblioteki.
Trochę nie czaję tej psychoanalizy, wszak biblioteka też może być projektem.
Padły zarzuty, że nigdy nie powinno się usuwać już udostępnionych bibliotek, więc po prostu podałem kilka powodów, dla których może mieć to sens. Wydaje mi się, że skoro ktoś nie widzi w tym sensu, to znaczy, że po prostu się z takimi przypadkami nie spotkał w praktyce. A typowe dla sporej części programistów jest podejście z założeniem, że jeśli ktoś działa inaczej niż oni, to znaczy, że robi źle.
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.
To jak często mam sprawdzać, czy przypadkiem nie pojawiła się nowa wersja biblioteki w usłudze, której dotykam raz na rok? Jest, działa itd.
Spytaj swojego team leadera. :)
Jak dla mnie mniejszym kosztem jest konieczność aktualizacji przy okazji implementacji zmiany niż ciągłe udostępnianie niedziałających bibliotek.
O ile dobrze kojarzę, mowa o bibliotece jakoś tam wspomagającej uruchamianie wyrażeń regularnych. Usługi w chmurze też nie znikają z dnia na dzień, tylko są odpowiednio anonsowane z wyprzedzeniem
No to przecież ja napisałem o poinformowaniu z wyprzedzeniem.
Jeżeli mówimy o bibliotece wewnątrz organizacji, to perspektywa jest trochę inna.
Tak, nie, może.
To jest moja perspektywa, bo tym się zajmuje. Takie wewnętrzne biblioteki nieraz też mają więcej użytkowników niż te publicznie dostępne.
No i stawianie ogólnych tez na podstawie zignorowania jakiejś części rzeczywistości nie daje dobrych efektów.
Gdybym przestał rosnąć w wieku 9 lat, to pewnie nadal bym miał.
To było pytanie retoryczne. :P
Ale to jest zupełnie niezależne od tego czy stare wersje mają wisieć w repo czy nie.
Owszem, chciałem jedynie zwrócić uwagę na fakt, że to nie jest mój wymysł, ze używanie starych wersji jest problematyczne. Tak, żeby może odetkać komuś perspektywę.