Czy istnieje standardowa definicja tego, co stanowi zmianę wersji (zmiany)

Question

Obecnie jestem w biurokratycznym piekle w mojej firmie i muszę zdefiniować, co stanowi różne poziomy zmiany oprogramowania w naszych programach testowych. Mamy nieobliczalną praktykę, którą stosujemy wewnętrznie, ale szukam standardu (jeśli istnieje), aby odnosić się do naszego systemu jakości. Rozumiem, że systemy mogą się znacznie różnić między programistami, ale ostatecznie szukam przewodnika "najlepszej praktyki", co stanowi istotną zmianę, drobną zmianę itp. Chciałbym odnieść się do opublikowanego dokumentu w mojej opinii do naszego systemu jakości dla Cele ISO, jeśli to możliwe.

Wyjaśnienie oprogramowania opracowanego w mojej firmie jest używane wewnętrznie do testowania automatyki półprzewodników. Nie sprzedajemy tego kodu, a jego wersja jest przeznaczona wyłącznie do przechowywania danych. Używamy zmian x.y.z, aby uzyskać poziom zatwierdzenia i zatwierdzenia potrzebny do wydania.

Answer 1

Dobrą praktyką jest stosowanie 3 Poziom numery Weryfikacja:

xyz

x jest głównym y jest małoletni oo są poprawki

Ważną rzeczą jest to, że dwa różne oprogramowania wersje z tym samym x powinny mieć kompatybilność binarną. Wersja oprogramowania o wartości y większej od drugiej, ale ta sama wartość x może dodawać funkcje, ale nie może ich usuwać. Zapewnia to przenośność w obrębie tego samego numeru głównego. I na koniec z nie powinno zmieniać żadnych funkcjonalnych zachowań, z wyjątkiem poprawek.

---

Edit:

Oto kilka linków do wykorzystywanych systemów revision-number:

• http://en.wikipedia.org/wiki/Software_versioning
• http://apr.apache.org/versioning.html
• http://www.advogato.org/article/40.html

Answer 2

aby powiększyć na co @lewap powiedział, użyj

xyz

gdzie zmiany poziomu Z są niemal wyłącznie poprawki błędów, które nie zmieniają interfejsów lub obejmować systemy zewnętrzne

gdzie zmiany poziomu y rozszerzyć funkcjonalność i może zmienić interfejs UI/API, oprócz naprawiania poważniejszych błędów, które mogą dotyczyć zewnętrznych systemów,

gdzie zmiany na poziomie obejmują cokolwiek, od całkowitego przepisania/przeprojektowania, aż po zmianę struktur bazy danych na zmieniające się bazy danych (np. z Oracle do SQLServer) - innymi słowy wszystko, co nie jest spadek, który wymaga zmiany „port” lub proces „nawrócenia”

Answer 3

Dodam numer kompilacji do formatu x.y.z:

x.y.z.budować

x = główną cechą zmiana zmiana
y = drugorzędny funkcja
z = poprawki tylko
build = zwiększany za każdym razem kod jest kompilowany

tym numer kompilacji jest kluczowa dla celów wewnętrznych, gdzie ludzie próbujemy ustalić, czy dana zmiana binarna ma jakąś konkretną zmianę.

Answer 4

Myślę, że może się różnić, jeśli pracujesz nad oprogramowaniem wewnętrznym a zewnętrznym (produktem).

W przypadku oprogramowania wewnętrznego prawie nigdy nie będzie problemu z używaniem formalnie zdefiniowanego schematu. Jednak w przypadku produktu wersja lub numer wydania jest w większości przypadków decyzją handlową, która nie odzwierciedla żadnych kryteriów technicznych ani funkcjonalnych.

W naszej firmie x.y w schemacie numerowania x.y.z jest określany przez marketingowych chłopców i dziewczynki. Z i wewnętrzny numer kompilacji są określane przez dział R & D i wracają do naszego systemu kontroli wersji i odnoszą się do sprintu, w którym został wyprodukowany (sprint jest terminem Scrum dla iteracji).

Ponadto formalne zdefiniowanie pewnego poziomu kompatybilności między wersjami i wersjami może spowodować, że bardzo szybko przejdziesz w górę lub prawie się nie ruszysz. Może to nie odzwierciedlać dodatkowej funkcjonalności.

Answer 5

Uważam, że najlepszym podejściem do tego, abyście mogli to wyjaśnić swoim współpracownikom, są przykłady zaczerpnięte z dobrze znanych i udanych pakietów oprogramowania oraz sposobu, w jaki podchodzą do większych i drugorzędnych wersji.

Pierwszą rzeczą, którą chciałbym powiedzieć, jest to, że główna. Notacja kropek dla uwolnień jest stosunkowo niedawnym wynalazkiem. Na przykład, większość wydań systemu UNIX posiadała nazwy (które czasami zawierały bezsensowny numer), a nie numery wersji.

Ale zakładając, że chcesz użyć major.minor, numeracji, to główna liczba wskazuje wersję, która jest zasadniczo niezgodna z wieloma wcześniejszymi. Rozważ zmianę z Windows 2,0 na 3.0 - większość 2,0 aplikacji po prostu nie pasuje do nowych nakładających się okien w Windows 3,0. W przypadku mniej wszechogarniających aplikacji radykalna zmiana formatów plików (na przykład) może być powodem poważnej zmiany wersji - aplikacje graficzne często pracują w ten sposób.

Innym powodem dużej zmiany numeru wersji jest to, że użytkownik zauważa różnicę. Ponownie było to prawdą w przypadku zmiany z Windows 2.0 na 3.0 i był odpowiedzialny za sukces tych laterów. Jeśli Twoja aplikacja wygląda zupełnie inaczej, jest to poważna zmiana.

A dla mniejszego numeru wersji, jest to zwykle używane do wskazania chanhe, które w rzeczywistości jest dość duże, ale nie będzie to zauważalne dla użytkownika. Na przykład różnice między wersją Win 3.0 a Win 3.1 były dość duże, ale interfejs pozostał taki sam.

Jeśli chodzi o trzeci numer wersji, niewielu ludzi wie, że tak naprawdę oznacza to mniejszą ostrożność. Na przykład w mojej codziennej pracy używam kompilatora GNU C++ w wersji 3.4.5 - jak to się różni od 3.4.4 - nie mam pojęcia!

Answer 6

Jak już powiedziałem w odpowiedzi na podobne pytanie: Użyta terminologia nie jest zbyt precyzyjna. Jest artykuł opisujący pięć istotnych wymiarów. Narzędzia do zarządzania danymi do tworzenia oprogramowania zazwyczaj nie obsługują więcej niż trzech z nich w tym samym czasie.Jeśli chcesz wesprzeć wszystkie pięć masz do opisania proce rozwojowe:

• wersja (semantyka: modyfikacja)
• View (semantyka: równoważności, pochodzenie)
• hierarchii (semantyka: składa się z)
• stanu (semantyka: zatwierdzenie, dostępność)
• wariant (semantyka: warianty produktu)

Peter van den Hamer i Kees Lepo etter (1996) Zarządzanie danymi projektowymi: Pięć wymiarów szkieletów CAD, zarządzanie konfiguracją i zarządzanie danymi produktu, Proceedings of the IEEE, Vol. 84, nr 1, styczeń 1996