Czy istnieje równoważny schemat do wersji semantycznej dla oprogramowania nieinterfejsowego?

Question

Bardzo podoba mi się schemat wersji semantycznej, ale ma on sens tylko w przypadku interfejsów API, ponieważ koncentruje się na przełamywaniu zmian i kompatybilności wstecznej. W przypadku nie-API, np. oprogramowanie użytkownika końcowego, wiele reguł nie ma już większego sensu. Na przykład sama koncepcja kompatybilności wstecznej tak naprawdę nie ma znaczenia; użytkownik doświadcza nowych funkcji lub ich nie ma, mniej błędów lub ich nie ma itp. Korzystałbym jednak z klarownego schematu dla wersji xyz, który jest zgodny z duchem wersji semantycznej, aby użytkownicy mogli mieć pojęcie, czego się spodziewać z nowych numerów wersji, jeśli znają schemat.

Próbowałem szkicując coś takiego jak:

• Bump Z Jeżeli dokonywania wewnętrznych zmian w kodzie (np poprawek, refactoring), które nie zmieniają wrażenia użytkownika. Mogą zawierać nowe funkcje "wewnętrzne".
• Bump y przy dodawaniu funkcji, które zmieniają doświadczenia użytkownika poza poprawkami błędów do bieżących funkcji.
• Bump x ... ??? ... radykalnie różne zmiany w odczuciach użytkownika? Co jest radykalnie różne?
• początkowym rozwoju alfa występuje w 0.0.z
• Pierwsze wydanie beta badania jest ustawiony 0.1.0 i pozostaje 0.yz
• Pierwsze wydanie użytkownika jest ustawiony na 1.0.0

innym Pomysł polega na zrobieniu x uderzeń, gdy funkcje, które są usunięte, ponieważ niektórzy użytkownicy mogą na nich polegać, ale w niektórych przypadkach może się to wydawać nieuzasadnione. (Powiedzmy, że znamy wszystkich użytkowników i wszyscy oni chcą, aby usunięto bardzo małą funkcję. Przechodzenie z wersji 1.0 na 2.0 byłoby nieco sprzeczne z intuicją.)

Jest to bardziej subiektywne niż Semantyczne Wersjonowanie, ponieważ łatwiej jest obiektywnie zidentyfikować funkcje kompatybilne z poprzednimi wersjami i funkcje łamania API. Czy są jakieś "znormalizowane" schematy wersjonowania, które mogę zbadać, aby uzyskać więcej wskazówek?

Answer 1

Jeśli oprogramowanie zapisuje pliki danych lub odczytuje pliki konfiguracyjne, a następnie co najmniej format tych plików to „API”, a więc zmiany w tym formacie będzie w zasadzie uzasadniać wpadając X.

Answer 2

byłem szukając czegoś podobnego samemu, ale nie znalazłem nic "oficjalnego". Oto jak ostatnio robię numerowanie wersji.

Biorąc x.y.z

• x = Przyrost kiedykolwiek przeprojektowanie doświadczenie użytkownika. Na przykład, możesz zmienić porządek na głównym interfejsie, tak jak zrobił to Microsoft w pakiecie Office 2003 w porównaniu z 2007. Jeśli Twoja aplikacja przechowuje pliki lub ustawienia użytkownika, ten numer również powinien zostać zwiększony, jeśli zmiany nie będą kompatybilne wstecz ze starszymi wersjami. pliki lub ustawienia.

• y = Zasadniczo inkrementacja po dodaniu nowego nowego podprogramu/funkcji. Generalnie rzeczy takie jak dodanie nowego elementu menu lub przycisku będą należeć do tej kategorii, ponieważ będziesz musiał napisać wywołanie zwrotne, aby obsłużyć zdarzenie kliknięcia w elemencie lub przycisku menu. Innym przykładem mogą być wszelkie zmiany w kodzie, które nie powodują zauważalnej różnicy dla użytkownika, ale poprawiają łatwość zarządzania (np.w końcu udało Ci się napisać klasę do zarządzania plikiem ustawień). Zresetuj tę liczbę, jeśli wzrasta x.

• z = Przyrost za każdym razem, gdy naprawiasz błąd. Zresetuj tę liczbę, jeśli zwiększana jest wartość x lub y.

Uwaga: Osobiście lubię myśleć, że jeśli uzyska y w podwójnych liczb dwucyfrowych, nadszedł czas, aby rozważyć przeprojektowanie interfejsu który użytkownika doprowadzić do wzrostu o x.