Witam,
tak jak w temacie, jakie jest wasze doświadczenie z tym zagadnieniem? Jak wy oznaczacie wersje i jak często? Rozumiem, że to zależy od wprowadzonych zmian, ale chciałbym też poznać wasze zmiany z przykładami z życia.

Podstawowy schemat: to A.B.C[-D], gdzie: A - główna wersja oprogramowania, B - podwersja, C - kolejna kategoria podwersji; D to opcjonalna "flaga" typu -ALPHA, -BETA, -RC, -SNAPSHOT.
Przykłady numeracji:

No i jak najlepiej z tego korzystać?
Powiedzmy, że zmieniłem jedną linię kodu dodając warunek w jakiejś metodzie:

[PHP] pobierz, plaintext 
$_class = ($_class != null) ? $_class : 'null';
[PHP] pobierz, plaintext 

Robię po takim dodaniu i sprawdzeniu tego commit na serwer.

Wprowadzenie zmian do projektu (commit) nie oznacza utworzenia nowej wersji programu. Wersje zmieniasz co jakiś czas, gdy przykładowo pojawi się jakaś nowa funkcja w programie.

Nie do końca. Temat wersjonowania opisuje standard, którego nazwy akurat nie pamiętam, ale jest to coś w tym stylu Semantic Versioning:

A.B.C (np. 2.23.7)

C - zmieniasz, kiedy sposób korzystania z programu i jego działania się nie zmienił, ale poprawiono np. błąd, lukę bezpieczeństwa itp.
B - zmieniasz, kiedy ogólny sposób działania programu się nie zmienił, ale dodałeś jakieś nowe funkcjonalności
A - kompletnie nowa aplikacja, np. przepisana od nowa, posiadająca zupełnie nowy interfejs, API itp.

A - Jak to przepisana od nowa? W jaki sposób?
B - dobrze rozumiem, nowa metoda, nowa klasa czy coś i wersja aplikacji się zmienia.

dorzuć do tego marketing i zarządzanie to powstanie zasada, aby A zawsze było większe niż u konkurencji

Szymciosek, nie patrz na to od strony technicznej tylko biznesowej

Chodzi o brak kompatybilności wstecznej ze starszymi wersjami (np. plik exportu z nowej wersji nie da się zaimportować do nowej starej, API działające ze starą wersją nie zadziała z nową itp).

Znalazłem opis standardu, o którym pisałem wcześniej. Polecam, bo to bardzo dobry opis: http://semver.org/