Numeracja Systemu YetiForce

01 numbers xyz2

Bardzo ważnym elementem jest odpowiednia numeracja systemu. Wiele dojrzałych systemów, które są na rynku od wielu lat, mają bałagan w numeracji. Tworząc własną wersje systemu, postanowiliśmy to uporządkować, dlatego przedstawiamy w kilku krótkich punktach poniżej zasady, jakimi będziemy się kierowali przy nadawaniu numeracji dla systemu.

Ogólnie

Numeracja będzie miała format X.Y.Z, gdzie X, Y i Z oznaczają liczby całkowite od zera w górę. 
Priorytety oznaczeń:
  • X - oznacza wydanie kolejnej dużej wersji systemu, która zawiera innowacyjne zmiany w porównaniu do wersji
  • wcześniejszej albo całość zmian z wersji wcześniejszych stanowią integralną całość nowej wersji.
  • Y - oznacza wydanie kolejnej wersji mniejszej względem X, ale będącej nadal istotną zmianą w porównaniu do Z. Zakłada się, że administrator systemu będzie
  • dążył do aktualizacji systemu nie rzadziej jak po wydaniu nowej wersji X lub Y.
  • Z - najczęściej zmieniane oznaczenie, które informuje o pojawieniu się nowej zmiany w systemie. Zmiana ta może zawierać zarówno mała poprawkę jak i dużą
  • zmianę, jednakże nie są wydawane paczki migracyjne pomiędzy poszczególnymi wersjami Z. Zmiany te możemy porównać na podstawie zmian w GitHub. Domyślnie paczki aktualizacyjne są tak zbudowane, aby przy aktualizacji nie wykonywały ponownie zmian, które wcześniej zostały wgrane.
Poszczególne oznaczenia (X, Y i Z) wzrastają niezależnie, przy czym zwiększenie oznaczenia wyższego rzędu powoduje zerowania oznaczeń niższych rzędów, np. gdy z wersji 1.5.435 przechodzimy na wersje 2 to ma ona postać 2.0.0. Każda nowa wersja systemu (każda nowa zmiana) musi zwiększać numeracje X.Y.Z.
  • Oznaczenie Z [wersja wstępna] - każda nowa zmiana w systemie w pierwszej kolejności będzie powodowała zwiększenie Z. W ten sposób będą wprowadzane poprawki do systemu określone jako testowe dla społeczności YetiForce. Istotne jest to, że pomiędzy poszczególnymi wersjami Z nie będą publikowane paczki migrujące (czyli producent nie będzie udostępniał narzędzi, które w prosty sposób pomogą w przejściu pomiędzy wersjami).
  • Oznaczenie Y [wersja sprawdzona] - gdy producent uzna wersje Z wprowadzone na GitHub za stabilne, a społeczność nie zgłosi w nich błędów, które oznaczają, że wprowadzone zmiany zawierają znaczące błędy wpływające na bezpieczeństwo lub stabilność to zostaje opublikowana kolejna wersja Y o jeden numer wyższa od poprzedniej wersji Y i zeruje numeracje Z.
  • Oznaczenie X [wersja końcowa] - co kilka miesięcy producent będzie publikował wersje produkcyjną, która po wprowadzeniu poprawek zgłoszonych w wersjach Y i Z będzie oznaczała wydanie wersji końcowej. Producent będzie publikował razem z tymi wersjami wersje migracyjne.

Paczka aktualizacyjna

Jest to zbiór poprawek zawierających zmiany albo z gałęzi Z (wtedy paczka aktualizacyjna pozwala przejść na nowszą wersje w gałęzi Y) albo z gałęzi Y (wtedy paczka zawiera inne paczki aktualizacyjne, które były publikowane razem z wersjami Y i ten zbiór poprawek pozwala przejść na nową wersje X). Producent nie będzie publikował paczek aktualizacyjnych dla wersji Z. Paczki aktualizacyjne dotyczą zawsze przejścia z wersji o numer niższej do wersji o numer wyższej. W praktyce oznacza to, że administrator systemu, który chciałby przejść z wersji np. 1.3 do wersji 1.6 powinien zainstalować paczki migrujące w wersjach 1.4, 1.5, a następnie 1.6. Wyjątek stanowi oznaczenie gałęzi X numerem 0, oznacza ona, że aż do wydania wersji X większej od jeden nie będą publikowane żadne paczki migracyjne. Można przyjąć wersje 0 jako wersje przygotowywaną do opublikowania.

Cykl życia systemu

Do oznaczeń nie wprowadzamy żadnych innych elementów takich jak: alpha, beta, rc, rtm, ponieważ uznajemy oznaczenia X.Y.Z za wystarczające i przejrzyste. Niejednokrotnie administrator systemu będzie wprowadzał wersje Z, które będą zawierały poprawki błędów, które on zgłosił i są mu konieczne do pracy z systemem lub wersje Z będą zawierały funkcjonalności istotne z punktu biznesowego, które będą wprowadzone w wyższych wersjach dopiero za kilka tygodni.

Wyjątek stanowi wersja 1.X.X, która aż do wersji 2.0.0 będzie oznaczana jako RC. Wersja 1.X.X jest wersją stabilną, ale każde oprogramowanie wymaga czasu i wielu wdrożeń, aby móc je w pełni nazwać oprogramowaniem przetestowanym i sprawdzonym w rzeczywistych wdrożeniach. Dlatego dla dużych korporacji zaleca się wdrożenie systemu od wersji 2.0.0.

  • poniedziałek, 07 sierpień 2017