Jednym ze sposobów definiowania wersjonowania jest nadanie znaczenia semantycznego każdej części:

• Przejdź z N. x do n+1.0, gdy zgodność zostanie przerwana z nowym relase
• Przejdź z N. m do N. m+1 po dodaniu nowych funkcji, które nie naruszają kompatybilności
• Przejdź z N. M. X do N. M. X+1 po dodaniu poprawek błędów

Powyższe jest tylko przykładem - chciałbyś zdefiniować zasady, które mają dla ciebie sens. Ale to bardzo miłe dla użytkowników, aby szybko powiedzieć, czy niezgodności oczekuje się po prostu patrząc na wersję.

Wersjonowanie semantyczne ma zestaw wytycznych i zasad, jak to zastosować (i kiedy). Bardzo proste do naśladowania i po prostu działa.

Http://semver.org/

Pierwszą rzeczą, którą polecam, jest zapoznanie się z różnicami pomiędzy wersją Assembly i wersją Pliku. Niestety,. NET ma tendencję do traktowania ich jako takich samych, jeśli chodzi o Pliki AssemblyInfo, ponieważ zwykle umieszcza tylko AssemblyVersion i pozwala FileVersion na domyślną wartość tej samej wartości.

Skoro powiedziałeś, że jest to Wspólne Zgromadzenie, zakładam, że masz na myśli to, że jest dzielone na poziomie binarnym (nie przez włączenie projektu do różnych rozwiązań). Jeśli w tym przypadku chcesz być bardzo świadomy o zmianie wersji Assembly, ponieważ tego używa. NET do silnej nazwy zespołu (aby umożliwić umieszczenie go w GAC), a także tworzy "pełną nazwę zespołu". Gdy wersja złożenia ulegnie zmianie, może ona zawierać zmiany zrywające dla aplikacji, które jej używają bez dodawania wpisów przekierowania złożenia w aplikacji.plik konfiguracyjny.

Co do nazewnictwa, to chyba zależy od tego ,jakie są zasady nazewnictwa Twojej firmy (jeśli takie istnieją) i celu biblioteka. W przypadku exmaple, jeśli ta Biblioteka zapewnia" podstawową " (lub systemową) funkcjonalność, która nie jest specyficzna dla konkretnego produktu lub linii biznesowej, można ją nazwać:

CompanyName.Framework.Core 

Jeśli jest częścią większej biblioteki, lub po prostu

CompanyName.Shared
CompanyName.Core
CompanyName.Framework

Jeśli chodzi o to, kiedy zwiększać numery wersji, to nadal jest to raczej subiektywne i zależy od tego, co uważasz za reprezentację każdej części numeru kompilacji. Domyślnym programem Microsoftu jest Major.Drobne.Buduj.Rewizji, ale to nie znaczy, że ty nie możesz wymyślić własnych definicji. Najważniejsze jest, aby być konsekwentnym w swojej strategii i upewnić się, że definicje i zasady mają sens we wszystkich twoich produktach.

W prawie każdej wersji schematu widziałem dwie pierwsze części są duże.Drobne. Główny numer wersji zwykle zwiększa się, gdy są duże zmiany i / lub zmiany łamiące, podczas gdy mniejszy numer wersji zwykle zwiększa się, aby wskazać, że coś się zmieniło, co nie było złamaniem zmiana. Pozostałe dwie liczby są znacznie bardziej subiektywne i mogą być " kompilacją "(która często jest liczbą seryjną lub sekwencyjnie aktualizującą numer, który zmienia się każdego dnia) oraz" rewizją " lub numerem poprawki. Widziałem też ich odwrócenie (dając Major.Drobne.Rewizja.Build), gdzie build to sekwencyjnie rosnący numer z automatycznego systemu budowania.

Należy pamiętać, że wersje major i minor asemblera są używane jako numer wersji biblioteki typów, gdy assembly jest eksportowany.

Wreszcie, spójrz na niektóre z tych zasobów, aby uzyskać więcej informacji:

Http://msdn.microsoft.com/en-us/library/51ket42z.aspx

Http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.aspx

Http://blogs.msdn.com/suzcook/archive/2003/05/29/57148.aspx