Poszukuję najlepszych praktyk w zakresie numeracji wersji zależnych składników oprogramowania

Staramy się wybrać dobry sposób numerowania wersji komponentów oprogramowania, które są od siebie zależne.

Bądźmy bardziej konkretni:

Komponent programowy A to oprogramowanie wewnętrzne działające na urządzeniu wbudowanym, a komponent B jest odpowiednim sterownikiem dla zwykłego komputera PC (komputer z systemem Linux / Windows). Komunikują się ze sobą za pomocą niestandardowego protokołu. Ponieważ nasz produkt jest skierowany również do programistów, zaoferujemy stabilne i niestabilne (eksperymentalne) wersje obu komponentów (oprogramowanie układowe jest typu open source, a sterownik typu open source). Naszą największą trudnością jest sposób obsługi zmian API w protokole komunikacyjnym.

Kiedy wdrażaliśmy kontrolę zgodności w sterowniku - sprawdza ona, czy wersja oprogramowania układowego jest zgodna z wersją sterownika - zaczęliśmy omawiać wiele sposobów numeracji wersji.

Wymyśliliśmy jedno rozwiązanie, ale chcieliśmy też wynaleźć koło na nowo. Dlatego chciałbym uzyskać informacje zwrotne od społeczności programistów / programistów, ponieważ uważamy, że jest to powszechny problem.

Oto nasze rozwiązanie:

Planujemy podążać za powszechnie stosowaną numeracją wersji major.minor.patch i używać parzystych / nieparzystych mniejszych liczb dla wersji stabilnych / niestabilnych. Jeśli wprowadzimy zmiany w interfejsie API, zwiększymy liczbę mniejszą.

Ta konwencja doprowadzi do następującej przykładowej sytuacji:

Obecna stabilna gałąź to 1.2.1, a niestabilna to 1.3.7. Teraz nowa poprawka dla niestabilnej zmiany API, co spowoduje, że nowy numer wersji niestabilnej zmieni się na 1.5.0. Gdy niestabilna gałąź zostanie uznana za stabilną, powiedzmy w 1.5.3, wydamy ją jako 1.4.0.

Z przyjemnością odpowiem na dowolne z poniższych pytań:

• Czy możesz zasugerować najlepszą praktykę rozwiązywania wyżej opisanych problemów?
• Czy uważasz, że nasza „niestandardowa” konwencja jest dobra?
• Jakie zmiany zastosowałbyś do opisanej konwencji?

Numery wersji IMHO są jak nazwy produktów; ważne, ponieważ są widoczne, ale nieważne, ponieważ są ozdobą, a nie treścią.

Nadal numer wersji, podobnie jak nazwa produktu, ma znaczenie. Najważniejsze, co możesz zrobić, to uniknąć zamieszania. Oto kilka typowych oczekiwań w odniesieniu do numerów wersji. W zakresie, w jakim te wyjątki nie są spełnione, użytkownik prawdopodobnie będzie zdezorientowany:

Numery wersji rosną monotonicznie.
Jest to prawdopodobnie najbardziej oczywiste oczekiwanie, a jednocześnie najmniej prawdopodobne, że rzeczywiście będzie prawdziwe. Na pierwszy rzut oka użytkownik oczekuje, że wersja 2.3.5 pojawi się po wersji 2.2.17 i ma tę samą lub lepszą technologię. Ale oczywiście 2.3.x jest gałęzią programistyczną , a 2.2.x jest stabilna , a wersja 2.3.5 faktycznie została wydana w 2004 roku, a gałąź 2.2 jest nadal aktywnie rozwijana , a wersja 2.2.17 została wydana dopiero w kwietniu ubiegłego roku i zawiera. .. cóż, masz pomysł. Równie dobrze możesz po prostu nazwać wersję 2.2 „Ziemniak”, co oznacza całe znaczenie liczby. Witamy w wersji „ Potato-17 ” !!

Podobne wersje można aktualizować / są kompatybilne
Jeśli mam wersję 3.7 na swoim komputerze, a 3.8 wychodzi ze wszystkimi nowymi błyszczącymi frozbotami, spodziewam się, że po jakiejś aktualizacji lub łatce, cokolwiek, mój 3.7 może stać się 3.8 bez żadnych zakłóceń. Ale jeśli korzystam z wersji 3.7, a ty wypuszczasz wersję 5.2, nie jestem tak optymistyczny. Oczywiście wolę raczej być mile zaskoczonym niż rozczarowanym.

Pierwsza cyfra jest znacząca
, nawet nie zawracałbym sobie głowy wspominaniem o tym, gdyby Java nie była tak wyraźnie myląca w tej sprawie. O ile ktoś ci nie powiedział, nie spodziewałbyś się, że „Java 7” to tak naprawdę wersja 1.7. I kiedy to usłyszałeś po raz pierwszy, twoja odpowiedź brzmiała prawie na pewno: „ Co? .. Dlaczego? ”

Oczywiście purysta powie, że główny numer wersji zmieni się tylko wtedy, gdy zmiana platformy nie będzie kompatybilna wstecz. Ale czy rzeczywiście zamierzasz kiedykolwiek porzucić zgodność wsteczną ? Często najważniejsze wersje są decyzjami marketingowymi, a nie technicznymi; absurdalność Jawy wywodzi się z obu obozów w tym samym czasie, co daje niemal komiczny efekt.

Wreszcie,
jak już wspomniałem, numery wersji często dotyczą zarówno marketingu, jak i technologii. I to jest w porządku, ponieważ do tego właśnie służą numery wersji: na pierwszy rzut oka informują Cię o nowościach w oprogramowaniu. Duża zmiana liczby oznacza dużą zmianę funkcjonalności. Mała zmiana liczby oznacza prawie brak zmiany funkcjonalności. Tego oczekują ludzie . To, czy jest to prawdą, czy nie, określa, czy numery wersji mają to samo znaczenie, co według użytkowników.

- EDYCJA -
zapomniałem o tym wspomnieć, ale Caleb ładnie to podkreślił: nie używaj numerów wersji do wskazywania czegoś ważnego (np. Stabilnego / niestabilnego), nie ujawniając go w innym miejscu. Tak, ty wiesz, że dziwny numer wersji moll wskazuje rozwój, ale sprawia, że jeden z nas. „Niestabilny” pseudonim wydania Debiana jest dobrym przykładem; lub możesz również użyć zupełnie innej nazwy produktu; „Frozbot 1.2” dla nazwy produktu i „Devbot 1.3” dla wersji programistycznej.

Gdy niestabilna gałąź zostanie uznana za stabilną, powiedzmy w 1.5.3, wydamy ją jako 1.4.0.

Nie? Nie. W przypadku niestabilnej wersji 1.5.3 stabilna musi zaczynać się od wersji 1.6.0 (i właśnie brakuje wersji 1.4.x, jeśli chcesz użyć wersji semantycznej)

Próbujesz użyć jednej wartości, aby wskazać dwie osobne rzeczy.

Po pierwsze, masz „wersję”, która zazwyczaj służy do identyfikacji różnych wydań i wskazania kolejności ich wydania. Jak powiedział Tylerl, wersja powinna zawsze się zwiększać - nie będzie to miało sensu dla użytkowników (i może spowodować wiele wewnętrznych nieporozumień), jeśli zmienisz wersję z 1.5.3 na 1.4.0.

Po drugie, próbujesz wskazać, czy dana wersja jest stabilna, czy nie.

Jest to możliwe , aby wskazać zarówno rzeczy z jednego „numeru wersji”, podobnie jak niektóre sklepy będą używać jakiś system ustalania cen, aby wskazać, czy dany element jest na sprzedaż. Na przykład ceny kończące się na „3” w sklepie blisko mnie są ostatecznymi cenami sprzedaży. Działa to dobrze dla pracowników, którzy szybko uczą się, jak rozpoznać cenę sprzedaży, ale nie jest to świetny sposób, aby poinformować klientów o sprzedaży. Z tego powodu umieszczają również znaki w pobliżu przedmiotów sprzedaży. Możesz zrobić coś podobnego, np. Zrobić najmniej znaczącą cyfrę nawet dla stabilnych wydań i uczynić ją dziwną dla wydań eksperymentalnych. Myślę jednak, że jeśli zamierzasz wydać coś eksperymentalnego, powinieneś to wyraźnie zaznaczyć. Możesz dodać „X” na początku lub na końcu łańcucha wersji, na przykład:X.1.5.31.5.3.X. Potem możesz nawet eksperymentalny numer wersji, więc możesz wydać wiele eksperymentalnych wersji, wszystkie oparte na tej samej wersji podstawowej: 1.5.3.X1, 1.5.3.X2.

Należy również wziąć pod uwagę, że istnieje długa tradycja stosowania „alfa” i „beta” numery wersji , aby wskazać wersje, które nie mogą być stabilne lub całkowite: 1.5.3a54. Upewnij się, że masz dobry powód do rezygnacji z tego programu, jeśli zdecydujesz się zrobić coś innego, ponieważ prawdopodobnie będziesz musiał wyjaśnić coś jeszcze swojej społeczności programistów.

Sugerowałbym użycie formatu major.minor.patch, używając rozszerzenia „tag” dla wersji stabilnych / niestabilnych oraz określonego znaczenia liczb głównych i pomocniczych:

major.minor.patch-stable|unstable

gdzie

major  only changes if there are incompatible changes in the API
minor  changes if there are changes in the API but backward compatibility is given
patch  any other changes, could be the build number or any other increasing number
-stable indicates the stable version
-unstable indicates the unstable version

W ten sposób zależności są łatwe do zarządzania i poinformują każdego klienta / użytkownika, kiedy muszą zwracać większą uwagę na nowe wersje. Np. Jeśli komponent A (stabilny w wersji 1.1.0) zależy od B (stabilny w wersji 5.4.534) i wymagana jest nowa wersja B (niestabilna w wersji 6.1.0), od razu wiadomo, że A będzie musiał zostać zmieniony, być może znacznie .

Naprawdę podoba mi się sposób, w jaki Hibernujące Nosorożce budują RavenDb w stosunku do wersji - mają tylko coraz większą liczbę wersji. Kiedy otrzymają stabilny, staje się oznaczony jako stabilny. Ale wszystko jest kandydatem do wydania.