Верзионисање софтвера је процес додељивања јединствених назива верзија или јединствених бројева верзија јединственим стањима рачунарског софтвера. Најшире прихваћена шема за бројеве верзија позната је као семантичко верзионисање (SemVer), која се састоји од троделног броја верзије (Major.Minor.Patch), опционе ознаке претиздања (нпр. alpha, beta) и опционе ознаке метаподатака изградње. Четврти број се такође може користити за означавање изградње софтвера, као што је био случај за Adobe Flash. Неке компаније се такође ослањају на датум изградње, у систему познатом као календарско верзионисање, и слова и друге карактере, као што је Lotus 1-2-3 Release 1a.
Већина слободних и софтверских пакета отвореног кода, укључујући MediaWiki, третира верзије као низ појединачних бројева, раздвојених тачкама, са прогресијом као што је 1.8.1, 1.9.0. С друге стране, неки софтверски пакети идентификују издања помоћу децималних бројева: 1.8, 1.81, 1.82. Програмери могу да изаберу да прескоче више мањих верзија одједном како би указали да су додате значајне функционалности или из маркетиншких разлога. Бројеви верзија се често користе за идентификацију копија софтверског производа и њихово поређење са другом копијом у колаборативном систему за контролу верзија.
Унутар тимова за развој софтвера, контрола верзија се користи за праћење постепено различитих верзија информација како би се омогућило враћање било којих измена. Савремени рачунарски софтвер се често прати коришћењем две различите шеме верзионисања: интерни број верзије, који може бити повећан много пута у једном дану, и верзија издања, која се обично мења много ређе.
Историјски, бројеви датотека су се посебно користили у јавној управи и корпорацијама да јединствено идентификују датотеке или предмете. Ова пракса је по први пут уведена у рачунарске датотеке са MИТ-овим ITS системом датотека, касније TENEX системом датотека за PDP-10 1972. године. У 21. веку, све више програмера је почело да користи стандардизовану политику верзионисања, као што је политика семантичког верзионисања, која је посебно корисна када се користе софтверске библиотеке, оквири и апликације командне линије.
Историја Бројеви датотека су се користили посебно у јавној управи, као и у компанијама, да јединствено идентификују датотеке или предмете. За рачунарске датотеке ова пракса је по први пут уведена са МИТ-овим ITS системом датотека, касније TENEX системом датотека за PDP-10 1972.
Касније су додате листе датотека укључујући њихове верзије, и зависности међу њима. Linux дистрибуције као што је Debian, са својим dpkg, рано су креирале софтвер за управљање пакетима који је могао да решава зависности између њихових пакета. Први покушај Debian-а био је да пакет познаје друге пакете који зависе од њега. Од 1994. године ова идеја је обрнута, тако да пакет познаје пакете који су му потребни. Приликом инсталације пакета, резолуција зависности је коришћена да аутоматски израчуна потребне пакете и да их инсталира заједно са жељеним пакетом. Да би се олакшала ажурирања, уведене су минималне верзије пакета. Стога је шема нумерисања морала да показује која је верзија новија од захтеване.
Шеме
Засноване на идентификаторима секвенци У шемама верзионисања софтвера заснованим на секвенцама, сваком издању софтвера се додељује јединствени идентификатор који се састоји од једне или више секвенци бројева или слова.Ово је опсег заједничког; шеме се значајно разликују у областима као што су број секвенци, приписивање значења појединачним секвенцама и начини повећавања секвенци.
Значај промене У неким шемама, идентификатори засновани на секвенцама се користе да пренесу значај промена између издања. Промене се класификују по нивоу значаја, а одлука о томе коју секвенцу променити између издања заснива се на значају промена у односу на претходно издање, при чему се прва секвенца мења за најзначајније промене, а промене у секвенцама након прве представљају промене опадајућег значаја.
У зависности од шеме, значај се може процењивати према линијама кода које су измењене, функцијским поенима који су додати или уклоњени, потенцијалном утицају на кориснике у смислу рада потребног да се усвоји нова верзија, ризику од грешака или непријављених некомпатибилних промена, степену промена у визуелном изгледу, броју нових функција, или готово било чему што програмери или маркетинг сматрају значајним, укључујући маркетиншку жељу да се нагласи „релативна доброта“ нове верзије.
Семантичко верзионисање Семантичко верзионисање (такође познато као SemVer) је широко прихваћена шема верзионисања која кодира верзију троделним бројем верзије (Major.Minor.Patch), опционом ознаком претиздања и опционом ознаком метаподатака изградње. У овој шеми, ризик и функционалност су мере значаја. Некомпатибилне промене се означавају повећањем главног броја (велики ризик); нове, компатибилне функције повећавају мањи број (средњи ризик); а све друге компатибилне промене повећавају patch број (најнижи ризик). Присуство ознаке претиздања (-alpha, -beta) указује на значајан ризик, као и главни број нула (0.y.z), који се користи да означи рад у току који може садржати било који ниво потенцијално некомпатибилних промена (највећи ризик). Као пример закључивања компатибилности из SemVer верзије, софтвер који се ослања на верзију 2.1.5 неког API-ја је компатибилан са верзијом 2.2.3, али не нужно и са 3.2.4.
Остале шеме Четврти број се такође може користити за означавање изградње софтвера, као што је био случај за Adobe Flash. Неке компаније такође укључују датум изградње и слова и друге карактере, као што је Lotus 1-2-3 Release 1a.
Програмери могу изабрати да прескоче више мањих верзија одједном како би указали да су додате значајне функције, али недовољне да оправдају повећање главног броја верзије; на пример, Internet Explorer 5 од 5.1 до 5.5 или Adobe Photoshop 5 до 5.5. Ово може бити учињено да се нагласи вредност надоградње за корисника или, као у случају Adobe-а, да представи издање на пола пута између главних верзија (иако нивои верзионисања заснованог на секвенцама нису нужно ограничени на једну цифру, као у Blender верзији 2.91 или Minecraft Java Edition почев од 1.7.10 до 1.21.10, након чега је шема верзионисања прешла на формат заснован на години).
Другачији приступ је коришћење главних и мањих бројева заједно са алфанумеричким низом који означава тип издања, нпр. „alpha“ (a), „beta“ (b) или „release candidate“ (rc). Низ издања софтвера који користи овај приступ може изгледати као 0.5, 0.6, 0.7, 0.8, 0.9 → 1.0b1, 1.0b2 (са неким исправкама), 1.0b3 (са више исправки) → 1.0rc1 (ако је довољно стабилан), 1.0rc2 (ако се пронађе више грешака) → 1.0. Уобичајена пракса у овој шеми је да се нове функције и некомпатибилне промене „закључају“ током фаза release candidate, а код неких тимова чак и током бета фазе, остављајући само исправке грешака, како би се осигурало приближавање циљном издању.
Друге шеме дају значење појединачним секвенцама:
major.minor[.build[.revision]] (пример: 1.2.12.102)
major.minor[.maintenance[.build]] (пример: 1.4.3.5249)
Поново, у овим примерима, дефиниција шта представља „главну“ у односу на „мању“ промену је потпуно субјективна и зависи од аутора, као и шта дефинише „build“, или како се „revision“ разликује од „мање“ промене.
Дељене библиотеке у Linux-у и Solaris-у могу користити формат current.revision.age где:
current: Најновији број интерфејса који библиотека имплементира.
revision: Број имплементације тренутног интерфејса.
age: Разлика између најновијег и најстаријег интерфејса који библиотека имплементира. Ова употреба трећег поља је специфична за libtool: други могу користити другачије значење или га једноставно игнорисати.
Сличан проблем релативног значаја промена и номенклатуре верзија постоји у издаваштву књига, где се бројеви или називи издања могу бирати на основу различитих критеријума.
У већини власничког софтвера, прва објављена верзија софтверског производа има верзију 1.
Степен компатибилности Неки пројекти користе главни број верзије да означе некомпатибилна издања. Два примера су Apache Portable Runtime (APR) и FarCry CMS.
Често програмери пишу нови софтвер тако да буде уназад компатибилан. На пример, IBM z/OS је дизајниран да ради исправно са 3 узастопне главне верзије оперативног система који ради у истом sysplex-у. Ово омогућава људима који управљају кластером високе доступности да већину рачунара одржавају у раду док се једна машина искључује, надограђује и враћа у рад.
Често заглавља пакета и формати датотека садрже број верзије - понекад исти као број верзије софтвера који га је направио; у другим случајевима „верзија протокола“ независна од верзије софтвера. Код за руковање старим, застарелим протоколима и форматима датотека често се сматра „cruft“-ом.
Означавање фазе развоја Софтвер у експерименталној фази (alpha или beta) често користи нулу у првој („главној“) позицији да означи свој статус. Међутим, ова шема је корисна само за ране фазе, а не за будућа издања код већ успостављеног софтвера где је број верзије већ прешао 0.
Користи се више шема за означавање статуса новијег издања:
Алфанумерички суфикс је уобичајена шема усвојена у семантичком верзионисању. У овој шеми, верзије имају додатак у виду цртице плус алфанумерички карактери који указују на статус.
Нумерички статус је шема која користи бројеве да означи статус као да је део секвенце. Типичан избор је трећа позиција у четворопозиционом верзионисању.
Нумерички 90+ је друга шема која користи бројеве, али испод броја претходне верзије. Велики број у последњој позицији, обично 90 или више, се користи. Ово се често користи код старијих open-source пројеката као што је Fontconfig.
Поређење показатеља фазе развоја Development stage | Semantic versioning | Numeric status | Numeric 90+
Alpha | 1.2.0-a.1 | 1.2.0.1 | 1.1.90
Beta | 1.2.0-b.2 | 1.2.1.2 | 1.1.93
Release candidate (RC) | 1.2.0-rc.3 | 1.2.2.3 | 1.1.97
Release | 1.2.0 | 1.2.3.0 | 1.2.0
Post-release fixes | 1.2.5 | 1.2.3.5 | 1.2.5
Две чисто нумеричке форме уклањају посебну логику потребну за поређење „alpha < beta < rc < без префикса“ као у семантичком верзионисању, по цену мање јасноће.
Већина слободних и отворених софтверских пакета, укључујући MediaWiki, третира верзије као низ појединачних бројева раздвојених тачкама, са прогресијом као што су 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, 1.11.2 и тако даље. С друге стране, неки софтверски пакети идентификују издања децималним бројевима: 1.7, 1.8, 1.81, 1.82, 1.9 итд. Децималне верзије су биле уобичајене 1980-их, на пример код NetWare, DOS и Microsoft Windows, али су чак и 2000-их коришћене, на пример код Opera и Movable Type. У децималном систему, 1.81 је мања верзија након 1.8, док се одржавајућа издања (нпр. само исправке грешака) могу означити словним суфиксом, као што је 1.81a или 1.81b.
Стандардна GNU шема нумерисања верзија је major.minor.revision, али Emacs је значајан пример који користи другу шему где је главни број (1) изостављен и додата је ревизија корисничког сајта која је увек нула у оригиналним Emacs пакетима али се повећава код дистрибутера. Слично томе, бројеви Debian пакета имају префикс опционог „epoch“-а, који се користи да омогући промену шеме верзионисања.
У неким случајевима, програмери могу одлучити да ресетују главни број верзије. Ово се понекад користи да означи нову фазу развоја која се објављује. На пример, Minecraft Alpha је ишао од верзије 1.0.0 до 1.2.6, а када је објављена Beta, главни број је ресетован и ишао је од 1.0 до 1.8. Када је игра у потпуности објављена, главни број верзије је поново ресетован на 1.0.0.
Формат Неки пројекти користе негативне бројеве верзија. Један пример је SmartEiffel компајлер који је почео од −1.0 и бројао навише до 0.0.