Data jako numer wersji oprogramowania

Twórcy oprogramowania zwykle nie używają daty jako numeru wersji, chociaż format RRRRMMDD (lub jego warianty) wygląda na wystarczająco solidny, aby go użyć. Czy coś jest nie tak z tym schematem? Czy może dotyczy tylko ograniczonych „rodzajów” oprogramowania (takich jak produkcje własne)?

Jest to coś, na co będziesz musiał spojrzeć z kilku różnych punktów widzenia, ponieważ musisz wziąć pod uwagę potrzeby użytkowników, a także potrzeby oprogramowania i programistów.

Ogólnie rzecz biorąc, Twoi klienci nie będą zbytnio przejmować się tym, jaki będzie numer wersji oprogramowania, o ile wiedzą, że korzystają z czegoś nowszego (tj. Produkt 2012 jest nowszy niż Produkt 2010) i że wiedzą o tym jest aktualny, jeśli istnieją łatki, które można wdrożyć (np. Produkt 2012, aktualizacja 10). Jako takie, z punktu widzenia marki marki preferuję albo nazwane wydania (np. Windows XP, Windows Vista), a następnie ścisłą liczbę poprawek, które mogą być instalowane przez użytkowników.

To powiedziawszy jednak, pisanie oprogramowania, które sprawdza rzeczy łatwe dla użytkownika, sprawia, że ​​kod pod maską jest znacznie trudniejszy do napisania. Dlatego wolę prosty Major.Minorschemat wersji, choćby dlatego, że możesz wykonać proste porównanie liczb, aby sprawdzić, czy coś jest aktualne, jak poniżej:

// Check to see if we can handle the file version
if (this.Version < fileVersion) {
   throw new UnsupportedFileException("The file version is " + fileVersion.toString() + " which is not supported");
}
// Do stuff ...

Mówiąc krótko, generalnie nie dbam o to, jak duża jest liczba mniejsza (tj. 1,1024), co pozwala powyższemu systemowi na dalsze działanie. Ogólnie rzecz biorąc, numery wersji są interesujące tylko dla wewnętrznego rozwoju i tak naprawdę nawet nie widziałem, żeby wpływały na coś znacznie więcej niż tylko nadanie im dodatkowej liczby do śledzenia.

Jednak powyższe dwa schematy tak naprawdę nie dotyczą tylko środowisk, w których stosuje się ciągłe wdrażanie (np. Stack Exchange), czyli tam, gdzie preferuję jakąś datę, po której następuje numer wersji, jak się wydaje na stosie na Exchange Exchange strony. Powodem tego jest to, że wersje będą się zbyt często zmieniać w środowisku ciągłego wdrażania i może istnieć wiele wersji kodu rosnących w tym samym dniu, co uzasadnia numer wersji, a bieżąca data jest tak dobra, jak każda inna, do zepsucia rzeczy jeszcze więcej. Teoretycznie możesz po prostu użyć numeru wersji do wszystkiego, ale użycie bieżącej daty pozwala na wewnętrzne śledzenie głównych kamieni milowych, które mogłyby ułatwić omawianie.

Problem z użyciem daty polega na tym, że specyfikacje są zapisywane na podstawie liczb, a nie na dacie, kiedy jest to wymagalne.

„Ta funkcjonalność ma być w wersji 1. Druga funkcjonalność ma być w wersji 2.”

Nie można podać daty w specyfikacji, ponieważ data premiery może zostać pominięta.

Jeśli nie masz takiego formalnego procesu, który wymaga wcześniejszej identyfikacji różnych wydań, używanie dat jest w porządku; nie musisz dodawać kolejnej liczby do miksu.

Numery wersji prawdopodobnie nie zawierają dat, ponieważ ich kontekst jest powiązany ze specyfikacjami.
Numery kompilacji prawdopodobnie zawierają daty, ponieważ ich kontekst jest powiązany z momentem kompilacji.

Chociaż to podejście ma zalety, jak opisano, istnieją pewne wady, jeśli użyjesz daty jako numeru wersji:

• Wersje oparte na dacie są płaskie. W wersji 2.1.3 można zobaczyć numer wersji, numer pod-wersji i numer pod-wersji. Dzięki 20110119 możesz zobaczyć tylko, kiedy został napisany. Państwo może grupować wersje oparty na dacie przez miesiąc, ale jeszcze nie powie nic. Możesz mieć kilka powolnych miesięcy drobnego naprawiania błędów, a następnie dwa tygodnie ciężkiego kodowania, co spowoduje poważne wydanie. Daty tego nie mówią, tak jak zwykłe numery wersji.

• Jeśli naprawdę potrzebujesz codziennie zmieniać wersję i być może numer wydania, może to oznaczać, że nie masz prawidłowego procesu wydania, ale zamiast tego wszyscy szalenie zmieniają rzeczy i promują je na serwery produkcyjne, kiedy tylko chcą. Jeśli tak, masz problem z procesem, a użycie innego schematu numeru wersji nie rozwiąże go.

Wersje są często używane do przekazywania informacji o tym, jak różni się dana wersja oprogramowania od poprzedniej. Na przykład, jeśli uaktualnisz z 1.0 do 2.0 Acme, jest to znaczna aktualizacja, teoretycznie niosąca za sobą poważne zmiany.

Z drugiej strony aktualizacja z 1.0 do 1.1 jest drobną aktualizacją i teoretycznie niesie niewielkie, przyrostowe zmiany i poprawki błędów.

Reprezentacja w formacie daty byłaby trudna, chociaż można użyć mieszanki. Na przykład v1.0.YYYY.MMDD

Nie powtarzając dobrych pomysłów z innych odpowiedzi, mam na myśli problem, który nie został jeszcze rozwiązany.

Jeśli zdarzy ci się zrobić rozwidlenie, między starszą wersją dla kompatybilności wstecznej a nową wersją dla niekompatybilnej modernizacji, nie można ich rozróżnić według numerów wersji.

Na przykład jądro Linuksa zostało rozwidlone około 2000 roku do starej gałęzi 2.4.x, która prawdopodobnie nadal jest dziś obsługiwana i liczy się jako 2.4.199, podczas gdy nowa wersja ma wersję 2.6 przez wiele, wiele lat i jest 2.6.32 dla starszych systemów, ale 3.2 dla najnowszych jąder.

Jeśli masz dokumentację dotyczącą swoich wydań, podwoisz informacje i powiesz ludziom, że wersja 20120109 przybyła w 2012 roku 01/09. Mh Ale co, jeśli nastąpi wykrycie błędu w ostatniej chwili, a wydanie zostanie opóźnione o tydzień, ale dokumentacja, w której wspomniana jest nazwa, jest już gotowa, być może wydrukowana, informacja prasowa jest niedostępna i tak dalej. Teraz masz rozbieżność, która jest problematyczna, jeśli wersja 20120109 dotarła do 2012/01/13.

W SQL często dyskutowano o tym, czy identyfikatory powinny zawierać informacje semantyczne, a rezultatem jest zawsze: unikaj ich jak diabli! Tworzysz niepotrzebną zależność. To nie może być pożyteczne.

Ubuntu ze schematem 04/10 miał problem w 2006 roku, kiedy wersja 6.04 została opóźniona i stała się 6.06. W roku 3000 wkrótce będzie kolejny problem! :)

Istnieje wiele pakietów oprogramowania, które rzeczywiście używają daty jako wersji. Przychodzi na myśl Ubuntu, gdzie ich wersja to YY.MM. I numery kompilacji dla produktów pakietu Microsoft Office są również kodowanie daty wykonania. Jeff Atwood napisał post na blogu Coding Horror o numeracji wersji , w tym tę rekomendację:

O ile to możliwe, używaj prostych dat zamiast numerów wersji, szczególnie w publicznych nazwach produktów. A jeśli absolutnie, pozytywnie musisz użyć numerów wersji wewnętrznie, i tak ustaw je jako daty: pamiętaj o zakodowaniu daty kompilacji gdzieś w numerze wersji.

Moim zdaniem nie ma to znaczenia, dopóki jesteś konsekwentny i jesteś w stanie przejść od numeru wersji kompilacji (cokolwiek to jest) i przywołać wszystkie artefakty, które weszły do ​​tej kompilacji z twojego systemu kontroli wersji. Użytkownicy zazwyczaj wcale nie dbają o informacje o wersji, ale raczej o funkcjonalność zapewnianą przez system. Informacje o wersji mają dla deweloperów prawdziwą wartość.

Używaj wersjonowania semantycznego - w ten sposób masz pojęcie o rodzaju zmian wprowadzanych między wersjami bez konieczności sprawdzania samego kodu: http://semver.org/

Używanie numerów wersji jest sposobem pokazania, jak DUŻA jest zmiana

Na przykład 2.4.3 może oznaczać, że wersja 2 jest główną zmianą w całym systemie. .4 to niewielka aktualizacja. a ostatnia .3 to mała poprawka do tej wersji. W ten sposób łatwo można rozpoznać, ile zmieniło się między poszczególnymi wersjami.

Powiedziawszy, że wciąż widzę, że wiele osób używa dat lub numerów wersji SCM jako numerów wersji, o ile masz jakiś sposób na powrót do obsługi informacji o wersji i dokumentacji tego, co było w zakresie tego wydania, nie ma prawdziwego problemu.

Kilka dobrych odpowiedzi już tutaj, ale chciałbym wskazać przypadek, w którym stosowanie dat ma doskonały sens: małe biblioteki lub fragmenty kodu, w których kod będzie prawdopodobnie często aktualizowany, ale w drobnych kawałkach, a żadna wersja nie różni się dramatycznie od poprzedniej jeden.

Innymi słowy, mówię o sytuacjach, w których nie ma rzeczywistego „numeru wersji”, ale w zasadzie rodzaj codziennego zrzutu repozytorium.

Kiedy natrafiam na tego rodzaju rzeczy, zazwyczaj z zadowoleniem przyjmuję wybór, ponieważ bardziej przydatne jest, gdybym wiedział, że używam stosunkowo aktualnego skryptu / lib zamiast konkretnej wersji.

Daty jako numer wersji są dobre dla marketingu. Jeśli ludzie używają „Windows NT 5.0”, mogą nie zdawać sobie sprawy, że jest przestarzały. Ale jeśli ludzie nadal używają „Windows 2000”, od razu dowiedzą się, że to 12-letni system operacyjny i będą zachęcani do aktualizacji.

Utrudnia to jednak rozróżnienie między „głównymi” i „drobnymi” aktualizacjami.

Problem z użyciem dat jako numerów wersji

Odpowiedzi tutaj są dobre, ale nie widziałem, aby ktokolwiek zajął się tym problemem przy użyciu dat: użytkownik nie może określić, jak często wprowadzano modyfikacje.

Próbuję powiedzieć, że mogę powiedzieć, że Windows 3.1 i Windows 7 są daleko od siebie ... i być może są niezgodne. Windows 95 i Windows 2000 mówią mi tylko rok, w którym produkt został wprowadzony.

Na przykład w Pythonie wiem, że wersja 2.7.2 ewoluowała z wersji 2.4.6. Jeśli spojrzę dalej, zobaczę, że wersja 2.4.6 została wydana 19 grudnia 2008 r .; a ta wersja 2.7.2 została wydana 11 czerwca 2011 r. Na tej podstawie mogę sformułować opinię na temat stabilności (tj. częstotliwości wydania) produktu.

Jeśli zamiast tego Python użył dat wydania, nie wiem, jak można połączyć te produkty. Doprowadzi to do dalszych nieporozumień, ponieważ Python 3.1.4 został również wydany 11 czerwca 2011 r. (To samo co Python 2.7.2).

Krótko mówiąc, nie sądzę, że samo w sobie wersjonowanie dat jest cenne.

Nie podoba mi się ten pomysł z powodów opisanych już przez innych. Wystarczy użyć schematu major.minor.bugfix - istnieje powód, dla którego większość ludzi robi to w ten sposób.

Ale cokolwiek zrobisz: wybierz jeden schemat nazewnictwa wersji i trzymaj się go . Nie rób tego jak Windows, gdzie zmieniają schemat z każdą wersją. I nie rób tego jak Android, gdzie każde wydanie ma numer wersji API (8), numer wersji przeznaczony do marketingu (2.2) i głupią nazwę (Froyo).

Data jako wersja

Jeśli twój produkt nie jest sprzedawany, to samo użycie daty jest w porządku i prawdopodobnie przydatne. Jeśli sprzedajesz go i uaktualniasz, klienci chcą kupić model z określonym zestawem funkcji. O wiele łatwiej jest sprzedać je z ulepszeniem, jeśli ten model ma jasną nazwę, nie ma tak naprawdę znaczenia, co to jest, ale na przykład nikt tak naprawdę nie kupuje samochodu Forda 20 stycznia 2012, jakiego chcą Kia Model. To samo dotyczy oprogramowania. Podanie twardej nazwy i wersji modelu oznacza, że ​​ma on funkcje inne niż starsza. Dla mnie tylko randka tego nie robi, to znaczy, że to zrobiłem, nie może mieć nowych funkcji.

Schemat, którego używamy

Nie twierdziłem, że nasz system tworzy wyraźną markę, jak wyżej. Teraz używamy czteroczęściowego schematu. Numer wersji, stan, data i suma kontrolna.

1200_GLD_120120_F0D1

Może to być szew, ale pozwala nam mieć kilka wersji kompilacji dla wersji 1200, z których mogą korzystać nasi inżynierowie i rozróżniamy je według daty. Stan powiedzieć ludziom, jeśli jest to wersja testowa, wewnętrzny klient gromadzeniu łata lub zwalniania złoto. Suma kontrolna jest nowa, to pozwala inżyniera lub klienta, aby sprawdzić, że rzeczywiście pobrało poprawny z naszej dystrybucji.

Więc możemy mieć sekwencję

1200_TST_120110_EF45
1200_GLD_120120_F0D1
1201_FIX_120125_123E
1201_TST_120130_31A5
1201_TST_120131_FDFD

Zwykle odnosimy się do głównych numerów wersji do klienta, tj. „12”, ale klient otrzyma najnowszą złotą wersję 12, tj. 1200_GLD_120120_F0D1, chyba że potrzebuje poprawki.

Powiedzmy, że niektórzy klienci używają wersji drugiej produktu, a niektórzy dokonali aktualizacji do wersji trzeciej, a to uaktualnienie nie jest decyzją podjętą pochopnie.

Powiedzmy, że ostatnią wersją wersji drugiej jest 2.3.2, a wersja trzecia to 3.0.3. Teraz znajdziesz lukę, którą absolutnie trzeba naprawić, więc wypuszczasz 2.3.3 i 3.0.4 tego samego dnia. Czy widzisz, że data premiery jest zupełnie nieistotna? Być może przestałeś pracować nad wersją drugą w 2013 roku i od tego czasu wydałeś tylko kilka istotnych poprawek. Data nie ma znaczenia w porównaniu z numerem wersji.

Myślę, że to działa świetnie. Używam go do oprogramowania wewnętrznego (rrrr.mm.dd) i do niektórych programów open source, które wydałem.

Może nie działać we wszystkich przypadkach.

Technicznie nie może używać daty dla numeru wersji, ale może pokazywać numer daty dla klienta. Na przykład macOS 16.7.23 --- oznacza to, że: 23.7.2016

Myślę, że technologia nie jest problemem, problem polega na tym, jak się czujesz? Jeśli użyjesz numeru daty, dzięki któremu oprogramowanie będzie żywe, żywe, jak człowiek, który ma numer urodzinowy. Każdego roku dorastamy, to samo, co oprogramowanie rośnie.

Numer budynku wygląda jak maszyna, maszyna, brak żywych, brak życia.