w jaki sposób wersjonowanie semantyczne dotyczy programów bez interfejsu API

W http://semver.org/ - który moim zdaniem wydaje się być najczęściej stosowaną konwencją w wersjonowaniu - zaleca się zwiększenie głównego numeru wersji po wprowadzeniu zmiany, która psuje / modyfikuje API.

Istnieją jednak dwa powiązane scenariusze, których nie widzę, jak zastosować tę wytyczną:

1. Co jeśli mój kod nie oferuje żadnego interfejsu API? Jak powinienem zaktualizować swój kod?
2. Co się stanie, jeśli mój kod zacznie oferować interfejs API na późnym etapie tworzenia?

Semver jest głównie zaniepokojony wersjonowaniem bibliotek i pakietów w sposób, który pozwala uniknąć piekła zależności, w różnych jego wcieleniach. Jednak ideę Semver można rozszerzyć na wszelkiego rodzaju programy - każdy fragment kodu ma jakiś interfejs użytkownika lub jest całkiem bezużyteczny.

• Biblioteka programowania lub usługa sieci Web ma interfejs API.
• Oprogramowanie konsumenckie może mieć GUI.
• Programy wiersza poleceń mają zestaw przełączników i opcji.
• Pliki konfiguracyjne są również interfejsem użytkownika.

Na przykładzie oprogramowania konsumenckiego, takiego jak edytor tekstu:

• Zwiększ numer łaty, gdy wysyłasz poprawkę, np .: „ naprawiono błąd, w którym aplikacja zawsze ulega awarii we wtorek o 00:00 ”.
• Zwiększ liczbę pomniejszych numerów wersji, dodając nową funkcję, np .: „ dodano obsługę podkreślonego tekstu ”.
• Zwiększ główną wersję, gdy znacznie przebudujesz interfejs użytkownika lub przepisz wszystkie elementy wewnętrzne. Np .: „ Paski narzędzi używają zbyt dużej powierzchni ekranu. Interfejs użytkownika jest teraz obsługiwany tylko za pomocą gestów dotykowych ”- taka zmiana przerwałaby istniejące przepływy pracy.

Jednak wiele problemów, które Semver próbuje rozwiązać, nie istnieje poza obszarem zarządzania zależnościami. W aplikacjach konsumenckich wersja jest nie tylko wersją, ale także zasobem marketingowym.

• Firefox i Chrome wydają nowe wersje stosunkowo często i zwiększają swój główny numer wersji w każdym wydaniu. Powoduje to absurdalnie wysoką liczbę wersji (obie są obecnie po trzydziestce). Przeglądarka z wyższym numerem wersji musi być po prostu lepsza niż przeglądarka z niższym numerem wersji, prawda?

• Główny numer wersji systemu operacyjnego Apple OS X stał się częścią nazwy (X to 10 cyfr rzymskich), dzięki czemu podrzędny numer wersji jest skutecznym głównym numerem wersji.

• System operacyjny Ubuntu korzysta ze schematu wersjonowania year.month.patchlevel. Ułatwia to zapamiętanie wieku twojego systemu operacyjnego, ale znacznie trudniej jest ustalić, które wersje są kompatybilne i jak długo trwa wsparcie dla każdej wersji.

• Jądro Linuksa zwiększyło liczbę wersji z 2.6.39 do 3.0.0, ponieważ robiło 39się trochę duże i dla uczczenia 20. rocznicy Linuksa.

• Legendarny system składu TeX Donalda Knutha używa numeru wersji, który od wersji 3 jest zbieżny do π przez dodanie kolejnej cyfry w każdym wydaniu: 3.14159265… Oznacza to, że system zbliża się do doskonałości. Podobnie system Metafont jest zbieżny do e : 2.7182818…

Tak więc wiele aplikacji nie jest dobrze obsługiwanych przez Semver. Wybierz schemat kontroli wersji, który jest odpowiedni dla twoich użytkowników (niezależnie od tego, czy użytkownicy ci są innymi programistami czy konsumentami) i zachowaj spójność.