Jak zrobić numery wersji?

Moja firma tworzy produkt. Będzie to wersjonowane przez SVN. Jest to aplikacja internetowa, więc w zasadzie nigdy nie będzie wersji, która nie zawiera niektórych funkcji i dlatego zawsze mogłaby być oznaczona jako beta. Ale ponieważ będzie to produkt korporacyjny, naprawdę nie chcę, aby tam było „niestabilne ostrzeżenie”. Jak więc zabrałbyś się do wersjonowania? Czy wersja 1.0 jest stabilna? Czy data kompilacji powinna znajdować się w numerze wersji? Powiedzcie mi co myślicie!

[ major ]. [ minor ]. [ release ]. [ build ]

major : Naprawdę decyzja marketingowa. Czy jesteś gotowy, aby zadzwonić do wersji 1.0? Czy firma uważa, że ​​jest to wersja główna, za którą klienci będą musieli zapłacić więcej, czy też jest to aktualizacja aktualnej wersji głównej, która może być bezpłatna? Mniej decyzji badawczo-rozwojowej, a bardziej decyzji dotyczącej produktu.

minor : Zaczyna się od 0 za każdym razem, gdy zwiększana jest wartość major . +1 za każdą opublikowaną wersję.

wydanie : za każdym razem, gdy osiągniesz kamień milowy w rozwoju i wydasz produkt, nawet wewnętrznie (np. do kontroli jakości), zwiększ to. Jest to szczególnie ważne w komunikacji między zespołami w organizacji. Nie trzeba dodawać, że nigdy nie publikuj dwukrotnie tego samego „wydania” (nawet wewnętrznie). Zresetuj do 0 po minor ++ lub major ++.

build : Może to być wersja SVN, uważam, że działa najlepiej.

Przykłady
Mój obecny chrome: 83.0.4103.61

xyzg

przyrosty w g są niestabilne. (lub RC) przyrosty w z są stabilne i oznaczają poprawki błędów.
przyrosty w y są stabilne i oznaczają nowe funkcje.
przyrosty x są stabilne, główne wydanie bez 100% kompatybilności wstecznej.

Kiedyś napisałem rozbudowany „przewodnik po stylu wersjonowania” dla mojego dużego projektu. Projekt nie został zrealizowany, ale przewodnik po stylu jest nadal dostępny online . To moja osobista opinia, być może jest dla Ciebie pomocna (lub inspirująca).

Uwaga, to długi tekst i dotyczy wersjonowania komponentów, wersjonowania produktów i tym podobnych. Wyraża też zdecydowane opinie na temat niektórych schematów wersjonowania popularnych w społeczności OSS, ale ja je mam, więc je wyrażam. ;-)

Na przykład nie zgadzam się na używanie numeru wersji Subversion. Możesz chcieć zachować wydaną wersję, kontynuując rozwój w TRUNK, więc skonfigurujesz gałąź konserwacji - a wersja numeru wersji pójdzie na marne.

Edytować: Podsumowując, rozróżnia wersje plików źródłowych, składników i całego produktu. Wykorzystuje system oddzielnych xy versoning dla komponentów i produktu, z ładną współzależnością między nimi, co sprawia, że ​​śledzenie, która wersja komponentu należy do której wersji produktu, jest trywialne. Mówi również o tym, jak obsługiwać cykle alfa / beta / wydania / łatki bez uszkadzania systemu. W rzeczywistości jest to modus operandi dla całego cyklu rozwoju, więc możesz chcieć wybrać najlepszy. ;-)

Edycja 2: Ponieważ wystarczająca liczba osób uznała mój artykuł za przydatny, aby uczynić go „dobrą odpowiedzią”, zacząłem ponownie nad nim pracować. Wersje PDF i LaTeX są już dostępne, kompletne przepisanie, w tym lepszy język i grafika objaśniająca, nastąpi, gdy tylko znajdę na to czas. Dziękuję za głosy!

Poszukaj inspiracji w Wikipedii: „Wersjonowanie oprogramowania”

Inną „nową” i „stosunkowo popularną” opcją jest wersjonowanie semantyczne

Podsumowanie:

Biorąc pod uwagę numer wersji MAJOR.MINOR.PATCH, zwiększ:

1. GŁÓWNA wersja w przypadku niekompatybilnych zmian API,
2. MNIEJSZA wersja, gdy dodasz funkcje w sposób kompatybilny wstecz i
3. Wersja PATCH po wprowadzeniu poprawek zgodnych wstecz.

Dodatkowe etykiety metadanych w wersji wstępnej i kompilacji są dostępne jako rozszerzenia formatu MAJOR.MINOR.PATCH.

abcd

Przyrosty: kiedy
- d : poprawki błędów
- c : konserwacja, np. Poprawa wydajności
- b : nowe funkcje
- a : zmiana architektury

Obowiązkowa jest ostatnia z lewej, np. Jeśli jest na przykład nowa funkcja i naprawiony błąd, wystarczy tylko zwiększyć b .

Opierając się na moim doświadczeniu ze złożonym zarządzaniem zależnościami na poziomie platformy korporacyjnej i wersjonowaniem wydań, polecam podejście, które lubię nazywać wersjonowaniem półsemantycznym .

Zasadniczo opiera się na Semantic Versioning 2.0 ale nie jest tak rygorystyczny.

Segmenty wersji semantycznej:

<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]

Format segmentu wydania podstawowego:

MARKETTING.MAJOR.MINOR.PATCH

Każdy segment powinien zezwalać na znaki alfanumeryczne, ale w przypadku logicznych zmian przyrostowych zalecane są czyste cyfry.

Podobnie jak SemVer, polecam komponenty Major, Minor i Patch, aby reprezentowały warstwy kompatybilności wstecznej, ale zalecam również dodanie komponentu Marketingowego . Dzięki temu właściciele produktów, epiki / grupy funkcji i obawy biznesowe mogą zderzyć się z głównym komponentem niezależnie od kwestii zgodności technicznej.

W przeciwieństwie do innych odpowiedzi, nie polecam dołączania numeru kompilacji do segmentu podstawowego. Zamiast tego dodaj segment po wydaniu po znaku „+” (np. 1.1.0.0 + build.42). SemVer nazywa to metadanymi kompilacji, ale myślę, że segment po wydaniu jest bardziej przejrzysty. Ten segment doskonale nadaje się do deklarowania danych sufiksu jako niezwiązanych z informacjami o zgodności w podstawowym segmencie wydania. Do kompilacji z ciągłą integracją można wtedy nadać poprzedni numer wersji z przyrostowym numerem kompilacji, który resetuje się po każdej wersji podstawowej (np .: 1.1.0.0 -> 1.1.0.0 + build.1 -> 1.1.0.0 + build.2 -> 1.1.0.1). Niektórzy na przemian lubią umieszczać tutaj numer wersji svn lub git commit sha, aby ułatwić powiązanie z repozytorium kodu. Inną opcją jest użycie segmentu po wydaniu dla poprawek i poprawek, chociaż warto rozważyć dodanie w tym celu nowego podstawowego składnika wydania. Zawsze może zostać usunięty, gdy składnik poprawki jest zwiększany, ponieważ wersje są skutecznie wyrównane do lewej i posortowane.

Oprócz segmentów wydań i post-release, ludzie często chcą używać segmentu przedpremierowego, aby wskazać prawie stabilne wersje wstępne, takie jak alfa, beta i kandydaci do wydania. Podejście SemVer działa dobrze, ale zalecam oddzielanie składników numerycznych od klasyfikatorów alfanumerycznych (np .: 1.2.0.0 + alpha.2 lub 1.2.0.0 + RC.2). Zwykle należy podbić segment wydania w tym samym czasie, co dodanie segmentu po wydaniu, a następnie upuścić segment przedpremierowy, gdy następnym razem podbijesz segment wersji podstawowej (np .: 1.0.1.2 -> 1.2.0.0-RC.1 - > 1.2.0.0). Segmenty przedpremierowe są dodawane, aby wskazać, że nadchodzi nowa wersja, zwykle jest to tylko ustalony zestaw funkcji do bardziej dogłębnego testowania i udostępniania, który nie zmienia się z minuty na minutę w oparciu o więcej zatwierdzeń.

Piękno posiadania tego wszystkiego semantycznie zdefiniowanego w sposób, który obejmuje prawie wszystkie przypadki użycia, polega na tym, że można je analizować, sortować, porównywać i zwiększać w standardowy sposób. Jest to szczególnie ważne w przypadku używania systemów CI do złożonych aplikacji z wieloma małymi niezależnie wersjonowanymi komponentami (takimi jak mikrousługi), z których każdy ma własne zarządzane zależności.

Jeśli jesteś zainteresowany, napisałem parser semantyczny w języku ruby . Musiałem nie tylko używać tego wzorca, ale móc zarządzać innymi aplikacjami, które go używały.

„Numery wersji” są kwestią dotyczącą wewnętrznego systemu kontroli wersji. Numery wersji to inna sprawa (i powinny być różne).

Trzymaj się prostego systemu wydań MAJOR.MINOR (jak wersja 1.27), gdzie MAJOR to poziom kompatybilności (wersja 2.x jest niekompatybilna z wersją 1.x lub co najmniej różni się od niej), a MINOR to Twoje wydania poprawek lub drobne ulepszenia . Jeśli korzystasz z formatu XY, możesz również używać innych systemów, takich jak ROK.MIESIĄC (2009.12) lub ROK.RELEASE (2009.3). Ale tak naprawdę prawdopodobnie najlepiej trzymać się MAJOR.MINOR, chyba że masz dobry powód, aby tego nie robić.

Zdecydowanie nie używaj niczego, co nie pasuje do formatu XY, ponieważ utrudni to współpracę z dystrybucjami, witrynami z ogłoszeniami itp., A samo to może poważnie wpłynąć na popularność twojego projektu.

Użyj rozgałęzień i znaczników w (najlepiej dystrybuowanym) systemie kontroli wersji, aby oznaczyć określone wewnętrzne numery wersji jako odnoszące się odpowiednio do MAJORS i MINORS.

I tak, 1.0 powinien być stabilny. Wszystkie wydania powinny być stabilne, chyba że są oznaczone jako alfa, beta lub RC. Użyj alfabetu dla znanych-uszkodzonych i niekompletnych. Bety dla znanych-zepsutych. RC dla „spróbuj, prawdopodobnie zauważysz rzeczy, które przegapiliśmy”. Wszystko bez jednego z nich powinno (najlepiej oczywiście) zostać przetestowane, uznane za dobre, mieć aktualną instrukcję itp.

W dzisiejszych czasach bardzo popularne jest używanie po prostu numeru wersji Subversion.

Jeśli jest w SVN, dlaczego nie użyć numeru wersji SVN?

Jeśli spojrzysz na prawy dolny róg tej strony, zobaczysz numer wersji Stack Overflow, który jest numerem wersji SVN.

Wersjonowanie zależy od Ciebie; Umieściłem 1.0 na pierwszej wersji, do której byłem przekonany. Możesz chcieć szybko sprawdzić inne wersje, ponieważ niektórzy dostawcy oprogramowania wystawili 1.0 złą reputację.

Potrzebujesz sposobu na powiązanie numeru wersji z dokładną wersją używanej wersji, ale prawdopodobnie chcesz, aby był on przyjemny i prosty dla użytkowników końcowych. Rozważ użycie standardowych numerów wersji i oznaczenie repozytorium SVN dołączonym numerem wersji.

Chociaż samo przejście z numerem wersji Subversion jest ładne i proste, usuwa informacje z numeru wersji. Użytkownicy mogą uznać to za coś złego.

Zakładam, że twoja aplikacja internetowa będzie miała jakąś procedurę wdrażania, więc nie każda wersja w Subversion jest faktycznie publikowana. Ponieważ niemożliwe jest „z zewnątrz” (z perspektywy użytkownika) określenie, kiedy będą wydawane wydania i ile poprawek przejdzie między nimi kod, powoduje to, że liczby są niemal przypadkowe. Będą rosnąć i myślę, że niektóre można przypuszczać dystans od porównania dwóch wersji, ale nie za dużo.

Klasyczne numery wersji mają tendencję do „dramatyzowania” wydań, tak że użytkownicy mogą budować pewne oczekiwania. Łatwiej jest pomyśleć "Mam wersję 1.0, teraz jest wersja 1.1, dodając to i tamto, co brzmi interesująco" niż myśleć "wczoraj uruchomiliśmy wersję SO 2587, dziś jest to 3233, musi być dużo lepiej!".

Oczywiście ta dramatyzacja może być również zawyżona, ponieważ firmy wybierają numery wersji, które mają brzmieć bardziej interesująco, niż jest to motywowane faktycznymi różnicami w produkcie, myślę, że idąc z licznikami numerów wersji to trochę.

Schemat wersji: [major]. [Minor]. [Devrel] [mark]
[major]: zwiększ, jeśli masz drastyczną zmianę w rozwoju.
[minor]: przyrost, jeśli masz niewielką zmianę w rozwoju.
[devrel]: zwiększ, jeśli masz poprawkę błędu. Zresetuj do zera, jeśli major ++ lub minor ++.
[znak]: a, b lub rc: a to wydanie alfa, b to wydanie beta, a rc to kandydat do wydania. Zauważ, że wersje takie jak 1.3.57a, 1.3.57b lub 1.3.57rc są wcześniejsze niż wersja 1.3.57. Zacznij od 0.0.0.

Spędziliśmy zbyt dużo czasu na podejmowaniu decyzji, kiedy zwiększyć wersję główną. Niektóre sklepy rzadko to robią, więc będziesz mieć wydania takie jak 1.25.3, a inne zrobią to na zawsze, dając ci 15.0

Miałem tego dość i przekonałem wszystkich, że główny numer to tylko rok, a młodszy to tylko kolejne wydanie w ciągu roku. Wydawało się, że użytkownikom się to spodobało i wymyślenie kolejnego numeru wersji nie jest trudne.

Year.Release.build

• rok = bieżący rok
• release = liczba publicznych wydań z nową funkcjonalnością - resetowana do 1 każdego roku
• build = zwiększana dla poprawek błędów i wewnętrznych wydań

EDYTOWAĆ

** Teraz dotyczyło to wewnętrznej aplikacji, która była stale ulepszana **

Prawdopodobnie nie działałoby to w przypadku aplikacji komercyjnych, w których ważne jest wydawanie głównych wersji o różnych porach roku w celach marketingowych i finansowych.

Powodem, dla którego istnieje to pytanie, jest brak uzgodnionego sposobu zarządzania konfiguracją.

Sposób, w jaki lubię robić numer wersji, to po prostu zwiększanie liczby całkowitej od 1. Nie chcę wieloczęściowego numeru wersji, który będę musiał wyjaśnić lub udokumentować. I nie chcę używać numeru rev ​​SVN, ponieważ będzie to również wymagało wyjaśnienia.

Aby tak się stało, potrzebne byłyby skrypty wydania oprócz SVN

Mam bardzo małe doświadczenie w tej dziedzinie. Jednak oto, co bym zrobił:

1. Wybierz schemat numerowania wersji i trzymaj się go. Bądź konsekwentny.
2. Każda zmiana wersji powinna oznaczać znaczącą zmianę . To, jak mała zmiana jest znacząca i jakie poziomy zmian są odzwierciedlone w numerze wersji, zależy od Ciebie.

Oczywiście możesz po prostu użyć numeru wersji svn --- jak sugerowało wielu innych !!!

Mam nadzieję, że to pomoże.

Używamy prostej składni major.minor.julian_date.

Gdzie;

• major - Pierwsza wersja to 1, a następnie, gdy wprowadzamy nowe główne funkcje lub zmiany tak znaczące, że nie są kompatybilne wstecz, zwiększ tę liczbę.
• minor - główne wydania kamieni milowych. Liczba ta wzrasta dla każdej wersji pchanej przez produkcję.
• julian_date - w dniu juliańskim kompilacja została przeniesiona do kontroli jakości.

Przykład pierwszej wersji przeniesionej do kontroli jakości w dniu 15 stycznia to -> 1.0.015
Przykład pierwszej wersji przeniesionej do wersji produkcyjnej w dniu 3/4 to -> 1.1.063

Nie jest idealny, ale przydatny, ponieważ prawie codziennie wprowadzamy kompilacje do kontroli jakości.

Kilka dobrych informacji tutaj:

Kiedy zmieniać wersje pliku / zespołu

Przede wszystkim wersje plików i wersje zestawu nie muszą się ze sobą pokrywać. Zalecam zmianę wersji plików przy każdej kompilacji. Ale nie zmieniaj wersji zestawu przy każdej kompilacji tylko po to, abyś mógł odróżnić dwie wersje tego samego pliku; użyj do tego wersji pliku. Podejmowanie decyzji, kiedy zmienić wersje zestawu, wymaga omówienia typów kompilacji do rozważenia: wysyłki i niedostarczenia.

Kompilacje niedostarczane Ogólnie rzecz biorąc, zalecam utrzymywanie tych samych wersji zestawów niedostarczanych do wysyłki między kompilacjami wysyłanymi do wysyłki. Pozwala to uniknąć silnie nazwanych problemów z ładowaniem zestawu z powodu niezgodności wersji. Niektórzy wolą używać zasad wydawcy do przekierowywania nowych wersji zestawu dla każdej kompilacji. Jednak odradzam to w przypadku kompilacji niedostarczanych: nie pozwala to uniknąć wszystkich problemów z ładowaniem. Na przykład, jeśli partner x-kopiuje Twoją aplikację, może nie wiedzieć o konieczności zainstalowania zasad wydawcy. Wtedy Twoja aplikacja zostanie dla nich zepsuta, mimo że działa dobrze na twoim komputerze.

Jeśli jednak istnieją przypadki, w których różne aplikacje na tym samym komputerze muszą być powiązane z różnymi wersjami zestawu, zalecam nadanie tym kompilacjom różnych wersji zestawu, aby można było używać poprawnej dla każdej aplikacji bez konieczności używania LoadFrom / etc.

Kompilacje wysyłkowe Jeśli chodzi o to, czy zmiana tej wersji w przypadku kompilacji wysyłanych jest dobrym pomysłem, zależy to od tego, jak chcesz, aby powiązanie działało dla użytkowników końcowych. Czy chcesz, aby te kompilacje były umieszczone obok siebie czy na miejscu? Czy jest wiele zmian między tymi dwoma wersjami? Czy zamierzają złamać niektórych klientów? Czy obchodzi Cię, że je psuje (czy chcesz zmusić użytkowników do korzystania z ważnych aktualizacji)? Jeśli tak, należy rozważyć zwiększenie wersji zestawu. Ale z drugiej strony weź pod uwagę, że robienie tego zbyt wiele razy może zaśmiecać dysk użytkownika przestarzałymi zestawami.

Kiedy zmieniasz wersje zestawu Aby zmienić zakodowane na stałe wersje na nowe, zalecam ustawienie zmiennej na wersję w pliku nagłówkowym i zastąpienie zakodowanego na stałe w źródłach zmienną. Następnie uruchom preprocesor podczas kompilacji, aby umieścić poprawną wersję. Zalecam zmianę wersji zaraz po wysyłce, a nie tuż przed, aby mieć więcej czasu na wyłapywanie błędów z powodu zmiany.

Lub użyj swojego „myśli” numer wersji przecinkiem numer podwersji .. zB:

1.0.101 // wersja 101, wydanie

lub 1.0.101-090303 // z datą wydania, używam tego