Каква схема за номериране на версии препоръчвате? [затворено]

Има два добри отговора за това (плюс много лични предпочитания; вижте коментара на gizmo за религиозните войни).

За публични приложения стандартът Major.Minor.Revision.Build работи най-добре IMO - публичните потребители могат лесно да разберат каква версия на програмата имат и до известна степен колко остаряла е тяхната версия.

За вътрешни приложения, при които потребителите никога не са искали приложението, внедряването се управлява от ИТ и потребителите ще се обаждат на бюрото за помощ, установих, че Year.Month.Day.Build работи по-добре в много ситуации. По този начин този номер на версия може да бъде декодиран, за да предостави по-полезна информация на бюрото за помощ, отколкото публичната схема за номера на версиите.

В края на краищата обаче бих дал една препоръка преди всичко - използвайте система, която можете да поддържате последователна. Ако има система, която можете да настроите/настроите на вашия компилатор автоматично, използвайте я.

Най-лошото нещо, което може да се случи, е да пуснете двоични файлове със същия номер на версия като предишните - наскоро се занимавах с автоматизирани доклади за грешки в мрежата (приложение на някой друг) и стигнах до заключението, че Year.Month.Day. Номерата на версиите на компилациите, показани в дъмповете на ядрото, дори не са актуални за самото приложение (самото приложение използва начален екран с реалните числа - които, разбира се, не са извлечени от двоичния файл, както може да се предположи). Резултатът е, че нямам начин да разбера дали изхвърлянията при срив идват от 2-годишен двоичен файл (какво показва номерът на версията) или от 2-месечен двоичен файл и по този начин няма начин да получа правилния изходен код (без контрол на източника също! )

Аз съм голям почитател на семантичните версии

Както много други коментираха, това използва формата X.Y.Z и дава добри причини защо.

Ето какво използваме в нашата компания: Основни.Второстепенни.Версия на корекция.Номер на компилация.

Основната промяна включва пълен цикъл на пускане, включително маркетингово участие и т.н. Този брой се контролира от сили извън R&D (например на едно от местата, където работех, маркетингът реши, че следващата ни версия ще бъде '11' - за съвпадение на конкурент.Ние бяхме на версия 2 по това време :)).

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

Версията на корекцията нараства с една всеки път, когато официално се добави корекция към версията, обикновено включваща само корекции на грешки.

Компилирана версия се използва, когато е пусната специална версия за клиент, обикновено с корекция на грешка, специфична за него. Обикновено тази корекция ще бъде събрана за следващата корекция или второстепенна версия (и управлението на продукта обикновено маркира грешката като „ще бъде пусната за корекция 3“ в нашата система за проследяване).

Нашият отдел за научноизследователска и развойна дейност използва 1.0.0.0.0.000: MAJOR.minor.patch.audience.critical_situation.build

Моля, моля, не правете това.

Този вид въпрос е повече за религиозна война, отколкото за обективни аспекти. Винаги има тонове плюсове и минуси срещу една или друга схема за номериране. Всичко, което хората биха могли (или трябва) да ви дадат, е схемата, която са използвали и защо са я избрали.

От моя страна използвам схема X.Y.Z, всички са числа, където:

• X показва промяна в публичния API, която въвежда обратна несъвместимост
• Y означава добавяне на някои функции
• Z показва корекция (или корекция на грешка, или промяна на вътрешната структура, без да се засяга функционалността)

В крайна сметка използвам суфикс „Beta N“, ако искам обратна връзка от потребителите, преди да бъде направена официална версия. Без наставка "RC", тъй като никой не е перфектен и винаги ще има грешки ;-)

Ние предпочитаме major.minor.milestone.revision-build схема, където:

• major: Увеличава се след значителни архитектурни промени или важни подобрения във възможностите.
• minor: Малки промени и нови функции, които не изискват архитектурни промени.
• milestone: Indicates stability and maturity of the code:
  • 0 for development/pre-alpha
  • 1 за алфа
  • 2 за бета
  • 3 за кандидат за освобождаване (RC)
  • 4 за окончателно/производствено издание
• revision: Показва номер на версия, корекция или корекция на грешка.
• build: Уникални препратки към конкретни компилации или версии на приложение. Номерът на компилация е последователно цяло число, което обикновено се увеличава при всяко компилиране.

Примери:

• 1.4.2.0-798: Първа бета версия на версия 1.4, създадена от компилация номер 798.
• 1.8.3.4-970: 1.8-RC4, създаден от компилация номер 970.
• 1.9.4.0-986: Първа производствена версия на версия 1.9, създадена от компилация номер 986.
• 1.9.4.2-990: Второ издание на корекция на грешки на версия 1.9, създадено от компилация номер 990.

Тъй като производствените версии винаги имат 4 в своята 3-та цифра от низа на версията, цифрата може да бъде премахната за производствените версии.

Аз лично предпочитам MAJOR.MINOR.BUGFIX-SUFFIX, където SUFFIX е dev за версии за разработка (проверки за контрол на версията), rc1 / rc2 за кандидати за издаване и без суфикс за версии за издаване.

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

В случай на библиотека, номерът на версията ви казва за нивото на съвместимост между две версии и следователно колко трудно ще бъде надграждането.

Изданието за корекция на грешки трябва да запази двоичната съвместимост, изходния код и сериализацията.

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

Номерата на основните версии могат да нарушат и трите форми.

Написах повече за обосновката тук.

С гъвкавите практики за разработка на софтуер и приложенията SaaS, идеята за голямо срещу второстепенно издание изчезна - изданията излизат изключително често на регулярна основа - така че схема за номериране на изданията, която разчита на това разграничение, вече не е полезна за мен.

Моята компания използва схема за номериране, която взема последните 2 цифри от годината, в която е започнало изданието, последвано от номера на изданието в рамките на тази година.

И така, 4-тата версия, стартирана през 2012 г., ще бъде 12.4.

Можете да включите номер на версията на "поправка на грешка" след това, ако е необходимо, но в идеалния случай пускате достатъчно често, за да не са необходими често - така че "12.4.2".

Това е много проста схема и не ни създаде нито един от проблемите на други схеми за номериране на версиите, които съм използвал преди.

Разликата между политиката за номер на версия с близък и отворен код може също да идва от търговски аспект, когато основната версия може да отразява годината на издаване например.

Това, което правехме тук, е major.minor.platform.fix.

основен: Увеличаваме този брой, когато записаният файл от тази компилация вече не е съвместим с предишната компилация.
Пример: Файловете, записани във версия 3.0.0.0, няма да бъдат съвместим с версия 2.5.0.0.

незначителен: Увеличаваме този брой, когато е добавена нова функция. Тази функция трябва да се види от потребителя. Не е скрита функция за разработчика. Това число се нулира на 0, когато мажорът се увеличи.

платформа: Това е платформата, която използваме за разработка.
Пример: 1 означава .net framework версия 3.5.

поправка: Увеличаваме този брой, когато с тази нова версия са включени само корекции на грешки. Това число се нулира на 0, когато главният или второстепенният се увеличават.

Просто

Major.Minor.Revision.Build