Cześć.

Chciałem się spytać jak sie "tworzy" numer nowej wersji programu (skryptu). No np. php 4.3.2 - czy liczby 4, 3 i 2 coś oznaczają czy też są tylko wymysłem programisty.

Zauważyłem, że stylów oznaczania wersji jest conajmniej kilka(naście):

x.x.x - np. 2.13.9
x.x - np. 6.11
0.x - np. 0.3

Do tego dochodzą takie "znaczki" jak RC1, a, b, alpha....

Albo też można dodać znak 'v' przed numerem wersji.

Znacie inne sposoby?

------
Seth: zmienilem topik na lepiej opisujacy pytanie

Ja tam sie nie znam, ale na moje oko to tak:
x.1 - x oznacza nową wersję z dużą ilością zmian
1.x - x oznacza wersję z dodanymi nowymi funkcjami itd
1.1.x - x oznacza zmiany kosmetyczne, poprawki błędów itd,

beta - oznacza wczesna wersję
alpha - jeszcze wcześniejszą

v. przed numerkami - oznacza wersję (version).

natomiast wg mnie oznaczenie np. 0.3 oznacza wersję beta, która została przetestowana i wypuszczona, ale nie do konca jest sprawdzona.

Myślę dość podobnie.

A może niektóre programy mają pewien algorytm określający wersję .

W większości wypadków z jakimi się spotkałem jest tak jak opisał spenalzo, chociaż są np. takie pomysły jak w przypadku kernela linuksowego, że gdy środkowa liczba jest parzysta to jest to wersja stabilna, a gdy nieparzysta -- rozwojowa.

Sa rozne standardy wersjonowania.
Ponizej podalem jakiej konwencji ja uzywam:
Kategorie wersji:
Develope (dev/d) - kategoria dla dokumentow, ktore sa w fazie rozwojowej. Dostepne dla okreslonej grupy ludzi (przewaznie devloperow lub zaufanych czlonkow zespolu).

Alpha (alpha/a) - kategoria dla dokumentu, ktory przeszedl "glosowanie" - zostal zaakceptowany przez grupe developerow do dalszych trestow przez grupe testerow nalezacych do grona programistow zaufanych ale nie wchodzacych w sklad developerow.

Beta (beta/B) - kategoria przeznaczona dla szerszej grupy testerow - czlonkow pracujacych nad projektem zajkujacych sie glownie testowaniem aplikacji.

Relase Candidate (rc) lub Relase ® - kategoria dokumentu przeznaczona dla wszystkich zainteresowanych osob. Posiadajaca najmniej bledow niz powyzsze kategorie. Jest to czesciowo skonczony projetk, z wiekszoscia mozliwosci jakie bedzie posiadal produkt. Przewaznie dokument taki jest po to aby poprawic elementy, ktore uzytkownik koncowy uzna za zle rozwiazane (np. nawigacja w programie, kolory itp. itd.).

Final (final/f) - ostateczna wesja trafiajaca do klienta.

Numerowanie wersji:
<major>.<minor>.<path/build><kategoria wersji (patrz wyzej)>

<major> - numer charakteryzujacy wersje, ktora posiada znaczace zmiany nie ograniczajace sie do zalatania dziur. Czyli np. zmiana protokolu komunikacji z aplikacja, rodzajudokumentow itp. Ogolnie chodzi o dokument (program), ktory zostal napisany od wersji (kategorii) dev.

<minor> - wersja oznacza zmiany nie obejmujace podstawowych aspektow programu. Czyli np. dodanie nowej ikonki , poprawienie funkcjonalnosci itp.
Przy wersjach dev czesto minor jest = 0.

<path/build> - ?Jest to wersja aplikacji posiadajacej nowy path - latke, reperujaca jakas dziure/blad lub tez numer kompilacji programu (czesto inkrementowana przez kompilator)

Przyklady:
1.0.13beta
2.0.0dev
itd.

Stosuję system zbliżony do Setha:
Version.Release.Modyfication-Category, np. Struktura bazy projektu, który mam na warsztacie, to:

4.5.3-rc

Czwarta wersja (budowana od podstaw)
Piąte wydanie (piąta seria)
Trzecia modyfikacja w serii (coś, co zajęło minimum pół godziny pracy)
rc - wersja umieszczona na serwerze domowym, dostepna dla klienta.

Okreslenia kategorii jak u Setha.