Въпроса не е точно за version control а как точно се определя коя част от номерата на версията да се промени. Какво имам предвид - обикновено номера на версията е нещо такова:
1.20.3-4567

4567 е build номера и това е ясно, ама как се определя кой от другите номера да се промени като се правят някакви промени в софтуера. Мисълта ми е има ли някакви стандарти или общоприети правила, които да го казват това. Как се определя 3-то ли да се промени, 20-о ли или пък 1-то? Предполагам, че софтуерите за version control го правят автоматично, но ако нямам такъв софтуер, а номера на версията ми трябва да има такъв формат тогава какво правим, щото не искам просто да си ги изсмуча от пръста номерата ?

Не знам дали има такова нещо като стандартизация( а и не съм чувал) но при програмиране се настройва компилатора като версия,фирма,име на продукта и др. такива (ръчно).

Не съм чувал за стандарт, може и да има такъв де, не знам просто...
Има различни системи като най-практичната според мен е ползване на календара. Особено ако имате повечко проекти и като дойде оплакване за продукт Х, версия 1.23.324-3244 е много трудно да се ориентираш.
Докато с датите, поне знаеш от кога е верисята. Примерно Ubuntu 12.10 знаеш че е октомври 2012...
Допълнително може да си сложиш релийз и билд номерация. Примерно 12.10.4.0 е 4-ти релийз за 12.10, а 12.10.4.3 е 3-та кръпка на 4-ти релийз от съответния месец.

Много практично, не го знаех и не съм се сещал.

Това с датите ми харесва като идея.
14.12.4-1234 - версия 4, билд 1234 от декември 2014 г.

Ммммм дата може ама да я сложиш да е в първите ти две групи ми се струва малко .. не знам, лично на мен не ми допада, а и не изгелжда много клиентски. При нас горе долу първата цифра дава нещо като .... еволюция, т.е. м-у 1,2,3 рзликата е огромна, и като структура и технологии и т.н. Следващата е вече модификация в самия код но по съществена и последната е билда, примерно в момента имаме 3.1.315 и тъй като не правим съществени промени в архитектурата на кода си стои 1-ца вече година и нещо, иначе както се вижда има 315 билда.
В смисъл да се прилага нещо като ЕСКД-то да има някаква логика в тия ревизии а не просто да определя дата. Лично аз не мога да се сетя коя функционалност кога е добавяна, както и хората които пишат най-вероятно, но всички много добре занем каква е разликата между 1,2,3; при версиите почващи с 2 имахме и различия и във втората група, а сегашната версия вече е доста изчистена /пренаписана за 3-ти път / и добавянето на функции не изисква пипане на дълбоко.

Димитре, нямате ли някаква фирмена система за номериране?
И аз слагам дата, но най накрая. В началото се мъдри нещо като X.Y или X.Y.Z

Стандарт няма, в някои случаи се определя и от маркетинговия отдел . Аз съм виждал първа версия на софтуер пусната в продажба като 2.3.45 примерно, че клиентите много се плашат от 1.0.

Иначе има най-различни схеми, в Линукс ядрото преди имаха една система с четни/нечетни маркирайки стабилни и по-експериментални версии.

Друго, което е смислено според мен е схема major.minor.bugfix. Първото число е major release и се инкрементира когато има големи промени във функционалността или вътрешната работа на приложението. Често има някакви несъвместимости с предишни версии, примерно конфигурационни файлове и при ъпгрейд може да очакваш изненади. Второто minor relase, се увеличава когато са направени малки промени или добавена нова проста функционалност. Третото bugfix се увеличава, когато промените единствено оправят бъгове, но без да се добавят никакви нови функции или да се променят съществуващи.

Това, което ползваме е:

PROD-VAR-DATE.VER.REV

където PROD-VAR е продукта и варианта му. Първото е текст, второто е номер на продукта и/или варианта. Вариантите са важни, ако се прави различен фърмуер за един и същ хардуер. Примерно по-скъп вариант с повече функции и т.н.
Датата е ясна, версия и ревижън също.
Примерно "HAMMER_CHRG-5-1412.3.1"

Идеята е, че първите две PROD-VAR са необходими на сервиза, за да знае за какво е въпросния файл. Дали е за хамър, дали за голф и кой вариант точно. Датата дава представа от кога е тоя файл/фърмуер. Версия и ревизия дават информация на тестерите и съпорта. Ако се смени версията трябва да внимават, защото най-вероятно има нова функционалност и трябва всичко да се изтества. Ако е сменена само ревизията, значи най-вероятно е фикснат някой бъг само и трябва да се провери. Обикновено ревизиите са само за вътрешни тестове.

Няма такава стратегия и затова сега се опитвам да я създам. Досега фърмуер версията беше само едно число и всеки път като променим нещо го увеличавахме с едно. Сега обаче има изискване от правителството да е във формат, дето споменах по-горе. В началото си мислих да е както Радолин е написал - major.minor.bugfix-build, ама определянето кое е мейджър и кое майнор промяна е много субективно и затова ми се иска да е нещо по-така и това с година.месец.версия-билд засега ми харесва най-много, защото можем да си запазим текущата номерация на версиите и само да добавим отпред датата и отзад билда.
Ако ползваме IDE-та върху еклипс, кой софтуер за контрол на версиите мислите, че е най-подходящ? Някой тук ползва ли git да ми каже какво мисли за него?

Номерации правят някои от комерсиалните среди/компилатори. Това не е свързано с вершън контрола. Той от своя страна може да е централизиран като CVS и SVN или децентрализиран като GIT. Първите си номерират промените, може да я ползваш тая номерация, но не е много препоръчително. При вторите пък изобщо няма номерация, там се работи на чек суми.
При всички случаи най-разпространената практика е отделна номерация, най-малкото така си независим и програмистите могат да сменят вершън контрола без да се обясняват на сервизите, съпорта, тестерите и т.н.
Как точно ще е реализираш зависи от компилаторите. Някои както казах си го имат. При гцц се реализира обикновено с добавка към мейкфайла. Добавя се един version.h файл и таргети за различните начини на релийз. Примерно make test-release и make release. Съответно единия таргет ти увеличава ревижъна, другия ти сменя версията. Желателно е всичко да става автоматично, включително и да имаш проверка дали всичко е качено, ако не е да не прави релийз докато не си качиш промените. Идеята е програмиста да няма шанс да забрави нещо, затова всичко с една команда или един клик на мишката. Или става или не. Съответно като стане само си сменя номерата, компилира, таг-ва си вершън контрола, криптира, абе всичко.. ако трябва може и прес-релийз да разпраща, за да знаят всички, че е излязла нова версия
По принцип се прави лесно, но ако го правиш мултиплатформено има разни чепове... спомням си че бая време загубих, щото DATE() в бозата връща едно, пък под лайнукс друго...

GIT е за момента най доброто през което съм минал (CVS, SVN ...). Можеш да го настроиш спрямо твоя тертип на работа а не да се настройваш според него. Бърз е. Работи ефективно с branch-ове. Преименуването/местенето на файлове не е никакъв проблем (т.е. следи ги по съдържанието а не по името). Разпределен е - т.е. имаш копие на сорсовете на всяка машина което трепе няколко заека - не ти трябва постоянна връзка до сървъра за да работиш (т.е. взимаш си лаптопа вечерта, правиш каквото правиш, и като се върнеш в офиса засилваш всичко към сървъра), имаш бекъп на всички машини та ако ти се скапе компютъра загубите са само последните промени които си правил. Командите в команд лине са малко с шантави имена, но свикнеш ли им е ОК. (т.е. една команда като checkout или reset може да прави няколко различни неща и може ама много лошо да се омажеш ако не знаеш какво правиш). GUI-та не съм ползвал освен за diff (meld) и history (gitk) така че за тях не мога да коментирам. Питай ако имаш някакви по конкретни въпроси ...

Може би най добре е да хвърлиш за начало едно око на gitflow workflow http://nvie.com/posts/a-successful-git-branching-model/ - това е добра илюстрация колко е мощен гит и как трябва да се организира работата така че хем да не спираш разработка на нова версия, хем да правиш поправки по старите.

Също хубаво нещо е git blame - виждаш всяка сорс линия кога и от кого е направена ... безценно като се гонят бъгове, за да намериш синковеца който е чупил каруцата и да го питаш на 4 очи какво всъщност е искал да направи ...

Перфектното решение е git + Jira или openproject.org (има и други де) за управление на проекти/продукти/програмисти ... разбиваш задачите на под задачи, разпределяш ги на програмистите, следиш по всяка една кога и от кого е работено, какви промени са направени, разлики между планирано и реално отделено време и т.н.

Абе с години ама в тоя случай ще ти се появи версия 14.12 и 15.01 само през един месец и в тях еиднствената разлика може да е че някой му е скимало да преомени декларацията на една променлива. Чисто логически човек ще се чуди защо от 12 минаваш на 01 и увеличаваш версията, дали си минал още 88 подверсии версии ? Не знам, това с датат ае удачно за някои неща, примерно така генерираме намерата на карти, 0359 1412 и другите каквото дойде, т.е. страна за която е издадено и година месец, ама в случая това е достатъчно и носи важна информация която е нужна, кога е печатана партидата.

Това с git май ми се струва точно като за нас, защото обикновено лаптопите нямат връзка с мрежата, когато ги ползваме, а и поради ред причини нямаме VPN. Така че е супер, че може да работи на сървър и локално и после да се синхронизира.
Тони, логически 15.01 следва след 14.12, дори да не са дати. При нас няма да има проблем, защото няма изискване номерацията да бъде логична или не, има изискване само да се спази въпросния формат и после единственото важно нещо е да могат да се различават различните версии, а то това дори само билд номера да е променен пак е спазено.
Миро, няма да е мултиплатформено - става въпрос само за фърмуер и само за фрискелски чипове. За старите контролери преместиха Code Warrior-а на Еклипс, а за ARM-те направиха това новото KDS, което е пак върху Еклипс, така че всичко се свежда само до Еклипс под Уиндоус.

Dimitar, такава система се прави веднъж... после хората свикват с дадена организация и не е лесно да се разбутва. Особено ако решиш да направиш логиката в мейкфайл и не я коментираш добре след няколко месеца ще си забравил и хич няма да ти се бара.

Та искам да кажа, че ако от сега не го почнеш като мултиплатформено после ще е трудно. Нямам представа дали ще ви трябва, ти си знаеш, но обикновено е хубаво в една фирма да има поне един работещ не на основната платформа. Най-малкото за тестове и диагностика на различни проблеми.