From fbae1c3862deac33e453a6c3943963f9fb682222 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rado=C5=A1=20Mili=C4=87ev?= <40705899+rammba@users.noreply.github.com> Date: Sun, 31 Aug 2025 16:13:17 +0200 Subject: [PATCH 1/4] Introduce Serbian cyrillic --- lang/sr-Cyrl/index.md | 377 ++++++++++++++++++++++++++++++++++++ lang/sr-Cyrl/spec/v2.0.0.md | 377 ++++++++++++++++++++++++++++++++++++ 2 files changed, 754 insertions(+) create mode 100644 lang/sr-Cyrl/index.md create mode 100644 lang/sr-Cyrl/spec/v2.0.0.md diff --git a/lang/sr-Cyrl/index.md b/lang/sr-Cyrl/index.md new file mode 100644 index 00000000..0609d560 --- /dev/null +++ b/lang/sr-Cyrl/index.md @@ -0,0 +1,377 @@ +--- +title: Семантичко Верзионисање 2.0.0 +language: sr-Cyrl +author: Aleksandar Marinković, Radoš Milićev +--- + +Семантичко Верзионисање 2.0.0 +============================== + +Сажетак +------- + +За дати број верзије MAJOR.MINOR.PATCH, инкрементирајте: + +1. MAJOR (ГЛАВНУ) верзију када унесете некомпатибилне измене API-ја +1. MINOR (МАЊУ) верзију када додате уназад компатибилну функционалност +1. PATCH (ЗАКРПА) верзију када додате уназад компатибилне исправке bug-ова (грешака) + +Додатне ознаке за pre-release (предиздања) и метаподатке build-а (израде) доступне су као проширења +у формату MAJOR.MINOR.PATCH. + +Увод +------------ + +У свету управљања софтвером постоји ужасно место које називамо +„пакао зависности“. Како ваш систем расте и што више пакета +интегришете у свој софтвер, већа је вероватноћа да ћете се наћи +у овом стању дубоког очаја. + +У системима са мноштвом зависности, објављивање нових верзија пакета може брзо +постати кошмар. Ако су спецификације зависности сувише строге, налазите се у опасности +од закључавања верзије (немогућност надоградње пакета без неопходне +објаве нове верзије сваког зависног пакета). Такође, ако су спецификације зависности +исувише лабаве, неизбежно ће вас довести у ситуацију верзијског промискуитета +(под претпоставком компатибилности са више будућих верзија него што је разумно). +Пакао зависности је ситуација у којој се налазите када закључавање верзије и/или +верзијски промискуитет спречавају једноставно и безбедно напредовање пројекта. + +Као решење овог проблема, предлажемо једноставан скуп правила и +захтева који диктирају како се бројеви верзија додељују и инкрементирају. +Ова правила су заснована, али нису нужно ограничена на већ постојеће и широко +распрострањене уобичајене праксе које се користе у closed и open-source софтверу. +Како би овај систем функционисао, неопходно је прво објавити public (јавни) API. +Можемо то применити у документацији или у самом коду. У сваком случају, важно је да +API буде јасан и прецизан. Једном кад идентификујемо јавни API, измене преносимо +кроз спецификоване инкрементације броја верзије. +Размотримо формат верзије X.Y.Z (Major.Minor.Patch). Исправке bug-ова (грешака) који +не утичу на API инкрементирају patch (закрпа) верзију, уназад компатибилне промене +API-ја инкрементирају minor (мању) верзију, а уназад некомпатибилне промене +API-ја инкрементирају major (главну) верзију. + +Овај систем називамо „Семантичко Верзионисање“. Према овој шеми, бројеви верзија +и начин на који се мењају дају информације о коду који се налази под датом +верзијом, као и шта се мењало од једне верзије до друге. + +Спецификација Семантичког Верзионисања (SemVer) +------------------------------------------ + +Кључне речи "MUST" ("МОРА"), "MUST NOT" ("НЕ СМЕ"), "REQUIRED" ("НЕОПХОДНО"), "SHALL" ("ХОЋЕ"), "SHALL NOT" ("НЕЋЕ"), "SHOULD" ("ТРЕБА"), +"SHOULD NOT" ("НЕ ТРЕБА"), "RECOMMENDED" ("ПРЕПОРУЧЕНО"), "MAY" ("МОЖЕ") и "OPTIONAL" ("ОПЦИОНО") у овом документу треба +тумачити како је описано у [RFC 2119](https://tools.ietf.org/html/rfc2119). + +1. Софтвер који користи Семантичко Верзионисање MUST (МОРА) објавити public (јавни) API. +Овај API може бити декларисан у самом коду или постојати стриктно у документацији. +У сваком случају, SHOULD (ТРЕБА) да буде прецизан и свеобухватан. + +1. Нормалан број верзије MUST (МОРА) бити у формату X.Y.Z где су X, Y и Z +не-негативни цели бројеви који MUST NOT (НЕ СМЕЈУ) почињати са нулом. X означава +главну верзију, Y мању верзију, а Z закрпу. +Сваки елемент MUST (МОРА) се нумерички инкрементирати. На пример: 1.9.0 -> 1.10.0 -> 1.11.0. + +1. Једном кад је верзионисани пакет објављен, садржај те верзије MUST NOT (НЕ СМЕ) +се мењати. Свака измена MUST (МОРА) се објавити као нова верзија. + +1. Major (главна) верзија нула (0.y.z) је за иницијални развој. Било шта се MAY (МОЖЕ) мењати +у сваком тренутку. Тај public (јавни) API SHOULD NOT (НЕ ТРЕБА) се сматрати стабилним. + +1. Верзија 1.0.0 дефинише public (јавни) API. Начин на који ће се број верзије +инкрементирати након ове објаве зависи од овог public (јавног) API-ја +и измена на њему. + +1. Patch (закрпа) верзија Z (x.y.Z | x > 0) MUST (МОРА) се инкрементирати само када се додају уназад компатибилне исправке bug-ова (грешака). Исправке bug-ова (грешака) су +дефинисане као интерне промене које исправљају неправилно понашање. + +1. Minor (мања) верзија Y (x.Y.z | x > 0) MUST (МОРА) се инкрементирати ако је нова уназад +компатибилна функционалност уведена у јавни API. MUST (МОРА) се +инкрементирати када се нека од функционалности API-ја означи као deprecated (застарела). +MAY (МОЖЕ) бити инкрементирана уколико се уведу субстанцијално нове функционалности +или побољшања у оквиру приватног кода. MAY (МОЖЕ) укључивати patch (закрпа) промене. +Patch (закрпа) верзија MUST (МОРА) се ресетовати на 0 када се minor (мања) верзија инкрементира. + +1. Major (главна) верзија X (X.y.z | X > 0) MUST (МОРА) се инкрементирати ако се уназад +некомпатибилне промене уводе у јавни API. MAY (МОЖЕ) укључивати и minor (мање) +и patch (закрпа) промене. Patch (закрпа) и minor (мање) верзије MUST (МОРА) да се ресетују +на 0 када се major (главна) верзија инкрементира. + +1. Верзија pre-release (предиздања) MAY (МОЖЕ) бити означена додавањем hyphen-а (повлаке) +и низа идентификатора одвојених тачком непосредно након patch (закрпа) верзије. +Идентификатори MUST (МОРАЈУ) садржати само ASCII алфанумеричке знакове и повлаке +[0-9A-Za-z-]. Идентификатори MUST NOT (НЕ СМЕЈУ) бити празни. Нумерички идентификатори +MUST NOT (НЕ СМЕЈУ) почињати нулом. Верзије предиздања имају нижи приоритет од +повезане нормалне верзије. Верзија предиздања означава да је +верзија нестабилна и да можда неће бити задовољени +предвиђени захтеви компатибилности као што је означено њеном +повезаном нормалном верзијом. Примери: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, +1.0.0-x.7.z.92, 1.0.0-x-y-z.\-\-. + +1. Метаподаци build-а (израде) MAY (МОГУ) бити означени додавањем плус знака и низа +идентификатора одвојених тачком непосредно након patch (закрпе) или верзије предиздања. +Идентификатори MUST (МОРАЈУ) садржати само ASCII алфанумеричке знакове и повлаке +[0-9A-Za-z-]. Идентификатори MUST NOT (НЕ СМЕЈУ) бити празни. Метаподаци build-а (израде) MUST (МОРАЈУ) +се занемарити приликом одређивања приоритета верзије. Две верзије које се разликују +само у метаподацима build-а (израде), имају исти приоритет. Примери: 1.0.0-alpha+001, 1.0.0+20130313144700, +1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3\-\-\-\-117B344092BD. + +1. Приоритет се односи на начин којим се верзије у међусобно пореде. + + 1. Приоритет се MUST (МОРА) израчунати раздвајањем верзије на major (главну), + minor (мању), patch (закрпу) и идентификаторе предиздања (метаподаци + build-а (израде) немају улогу у одређивању приоритета). + + 1. Приоритет се одређује првом разликом када се упоређује сваки од идентификатора + са лева на десно: Major (главна), minor (мања) и patch (закрпа) + верзије се увек упоређују бројчано. + + Пример: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. + + 1. Када су major (главна), minor (мања) и patch (закрпа) једнаке, верзија предиздања + има нижи приоритет од нормалне верзије: + + Пример: 1.0.0-alpha < 1.0.0. + + 1. Приоритет између две верзије предиздања са једнаком major (главном), minor (мањом) и + patch (закрпа) верзијом MUST (МОРА) бити одређен упоређивањем сваког идентификатора одвојеног тачкама + са лева на десно док се не пронађе разлика на следећи начин: + + 1. Идентификатори који се састоје само од цифара упоређују се нумерички. + + 1. Идентификатори са словима или повлакама се упоређују лексички у ASCII + поретку. + + 1. Нумерички идентификатори увек имају нижи приоритет од ненумеричких + идентификатора. + + 1. Већи скуп ознака предиздања има виши приоритет од мањег скупа + ако су сви претходни идентификатори једнаки. + + Пример: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < + 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. + +Бакус–Наурова форма за валидне SemVer верзије +-------------------------------------------------- +``` + ::= + | "-" + | "+" + | "-" "+" + + ::= "." "." + + ::= + + ::= + + ::= + + ::= + + ::= + | "." + + ::= + + ::= + | "." + + ::= + | + + ::= + | + + ::= + | + | + | + + ::= "0" + | + | + + ::= + | + + ::= + | + + ::= + | "-" + + ::= + | + + ::= "0" + | + + ::= "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" + + ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" + | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" + | "U" | "V" | "W" | "X" | "Y" | "Z" | "a" | "b" | "c" | "d" + | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" + | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" + | "y" | "z" +``` + +Зашто користити Семантичко Верзионисање? +---------------------------- + +Ово није нова нити револуционарна идеја. Тачније, вероватно већ радите нешто +врло слично. Проблем је што нешто "слично" није довољно добро. Без +усаглашености са неком врстом формалне спецификације, бројеви верзија су +у суштини бескорисни за управљање зависностима. Давањем имена и јасних +дефиниција горе наведених идеја, постаје лако пренети своје намере +корисницима вашег софтвера. Једном када су ове намере јасне, коначно је могуће +направити флексибилне (али, не превише флексибилне) спецификације зависности. + +Једноставан пример може показати како пакао зависности уз Семантичко Верзионисање +остаје ствар прошлости. Замислите library (библиотеку) под називом "Vatrogasno_vozilo". +Неопходан јој је Семантичко Верзионисани пакет под називом "Merdevine." У тренутку креирања Vatrogasno_vozilo, +Merdevine су у верзији 3.1.0. Пошто Vatrogasno_vozilo користи неке функције +првобитно уведене у 3.1.0, можете безбедно спецификовати зависност од Merdevine +као већу или једнаку од 3.1.0, али мању од 4.0.0. Сада, када +Merdevine верзије 3.1.1 и 3.2.0 постану доступне, можете их унети у свој систем +управљања пакетима и бити сигурни да ће бити компатибилни са постојећим +зависним софтвером. + +Као одговоран програмер, ви ћете, наравно, желети да верификујете да ли +upgrade (надградње) пакета функционишу како је наведено. Стварни свет је махом неуређено место; +не можемо ништа урадити поводом тога сем да будемо опрезни. Оно што можемо учинити +је да усвојимо Семантичко Верзионисање које нам пружа разуман начин за објављивање и +надоградњу пакета, без потребе за покретањем нових верзија зависних пакета, +штедећи време и труд. + +Ако вам ово звучи пожељно, све што је потребно урадити да бисте почели да користите +Семантичко Верзионисање је да се декларишете као корисник и да потом следите правила. +Повежите овај сајт са својим README фајлом како би и други били свесни правила +и имали користи од њих. + +FAQ +--- + +### Како се носити са ревизијама 0.y.z у иницијалној фази развоја? + +Најједноставнији начин је да започнете иницијални развој објавом верзије 0.1.0 +и потом инкрементирате minor (мању) верзију за свако следеће издање. + +### Како да знам када треба објавити верзију 1.0.0? + +Ако се софтвер користи у продукцији, већ би вероватно требао бити +1.0.0. Ако већ имате стабилни API од којег корисници зависе, верзија би требала +бити 1.0.0. Уколико сте прилично забринути око компатибилности уназад, софтвер +би већ требао бити објављен под верзијом 1.0.0. + +### Зар ово не обесхрабрује рапидан развој и брзу итерацију? + +Major (главна) верзија нула је заправо предодређена рапидном развоју. Ако мењате API +сваки дан, требали би остати на верзији 0.y.z или на посебној грани за развој +радити на следећој major (главној) верзији. + +### Уколико и најситније уназад некомпатибилне измене у јавном API-ју захтевају увећавање major (главне) верзије, нећу ли врло брзо доћи до верзије 42.0.0? + +Ово је питање одговорног развоја и предвиђања. У софтвер +који има пуно зависног кода, некомпатибилне измене не треба +олако уводити. Трошкови надоградње могу бити значајни. +Ако морате повећати major (главну) верзију како бисте објавили верзију +са некомпатибилним изменама, морате размислити о утицају тих измена и +проценити однос укључених трошкова и користи. + +### Документација целокупног јавног API-ја захтева превише посла! + +Ваша одговорност као професионалног програмера је да правилно документујете +софтвер који је намењен корисницима. Управљање сложеношћу софтвера је +изузетно важан део одржавања ефикасности пројекта, а то је тешко урадити ако +нико не зна како да користи софтвер нити које методе може безбедно позвати. +Дугорочно, Семантичко Верзионисање и инсистирање на квалитетно дефинисаном +API-ју омогућиће да сви и све ради глатко. + +### Шта уколико случајно објавим уназад некомпатибилне измене као minor (мању) верзију? + +Чим приметите да сте прекршили спецификације Семантичког Верзионисања, +исправите грешку и објавите нову minor (мању) верзију која исправља проблем и +враћа компатибилност уназад. Чак и у таквим условима, није прихватљиво +модификовати верзионисане објаве. Ако је прикладно, +документујте верзију која крши спецификацију и обавестите кориснике +како би били свесни тога. + +### Шта учинити уколико изменим сопствене зависности без промене јавног API-ja? + +Такве измене сматрамо компатибилним јер не утичу на јавни API. +Софтвер који експлицитно зависи од истих зависности као и ваш сопствени пакет, +треба имати властите спецификације зависности, а аутор ће приметити евентуалне +конфликте. Да ли је промена на нивоу patch (закрпа) или minor (мање) верзије +зависи од тога да ли сте ажурирали своје зависности као исправке +bug-ова (грешака) или сте их увели као нове функционалности. У другом случају +можемо очекивати и додатни код, при чему се очигледно ради о инкременту minor (мање) верзије. + +### Шта уколико случајно изменим јавни API на начин који не одговара измени броја верзије (нпр. уведем некомпатибилну major (главну) измену у оквиру patch-а (закрпе))? + +Користите своју најбољу процену. Ако имате велики број корисника на које ће +промена јавног API-ја на жељено понашање значајно утицати, +најбоље је да објавите major (главну) верзију, иако би се исправак +могао сматрати patch-ом (закрпом). Запамтите, сврха Семантичког Верзионисања +је преношење значења путем измене броја верзије. Ако су такве +измене важне за ваше кориснике, користите број верзије да бисте их информисали. + +### Како поступати са deprecating (застарелим) функционалностима? + +Постојеће функционалности које застаревају саставни су део развоја софтвера и +често су неопходне како би развој напредовао. Кад означавате део јавног API-ја +као deprecated (застарели), потребно је пратити две ствари: (1) ажурирати документацију +како бисте информисали кориснике, (2) објавити нову minor (мању) верзију са дефинисаним +deprecated (застарелим) деловима софтвера. Пре него што потпуно уклоните функционалност +у новој major (главној) верзији, потребно је издати барем једну minor (мању) верзију која +садржи deprecated (застареле) делове, како би корисници несметано прешли на нову верзију API-ја. + +### Има ли SemVer ограничење за величину стринга верзије? + +Не, али процените сами. Стринг верзије од 255 знакова је вероватно претеран, +на пример. Такође, неки системи могу имати своја ограничења +величине стринга. + +### Да ли је "v1.2.3" семантичка верзија? + +Не, "v1.2.3" није семантичка верзија. Међутим, додавање префикса "v" на семантичку +верзију је уобичајен начин (на енглеском) да се назначи да је то број верзије. +Скраћење "version" на "v" се често види у контроли верзија. Пример: +`git tag v1.2.3 -m "Release version 1.2.3"`, где је "v1.2.3" назив +tag-а (ознаке), а семантичка верзија је "1.2.3". + +### Да ли постоји предложени регуларни израз (RegEx) за проверу SemVer стринга? + +Постоје два. Један са именованим групама за оне системе који их подржавају +(PCRE [Perl Compatible Regular Expressions (Perl компатибилни регуларни изрази), тј. Perl, PHP и R], Python +и Go). + +Погледајте: + +``` +^(?P0|[1-9]\d*)\.(?P0|[1-9]\d*)\.(?P0|[1-9]\d*)(?:-(?P(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ +``` + +И други са нумерисаним групама (znači cg1 = major (главна), cg2 = minor (мања), +cg3 = patch (закрпа), cg4 = prerelease (предиздање) и cg5 = buildmetadata (метаподаци)) који су компатибилни +sa ECMA Script (JavaScript), PCRE [Perl Compatible Regular Expressions (Perl компатибилни регуларни изрази), +тј. Perl, PHP и R], Python и Go. + +Погледајте: + +``` +^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ +``` + +О пројекту +----- + +Аутор спецификације Семантичког Верзионисања је [Tom +Preston-Werner](https://tom.preston-werner.com), проналазач Gravatar-а +и суоснивач GitHub-а. + +Ако желите оставити повратне информације, молимо [отворите issue на +GitHub-у](https://github.com/semver/semver/issues). + +Лиценца +------- + +[Creative Commons ― CC BY 3.0](https://creativecommons.org/licenses/by/3.0/) diff --git a/lang/sr-Cyrl/spec/v2.0.0.md b/lang/sr-Cyrl/spec/v2.0.0.md new file mode 100644 index 00000000..0609d560 --- /dev/null +++ b/lang/sr-Cyrl/spec/v2.0.0.md @@ -0,0 +1,377 @@ +--- +title: Семантичко Верзионисање 2.0.0 +language: sr-Cyrl +author: Aleksandar Marinković, Radoš Milićev +--- + +Семантичко Верзионисање 2.0.0 +============================== + +Сажетак +------- + +За дати број верзије MAJOR.MINOR.PATCH, инкрементирајте: + +1. MAJOR (ГЛАВНУ) верзију када унесете некомпатибилне измене API-ја +1. MINOR (МАЊУ) верзију када додате уназад компатибилну функционалност +1. PATCH (ЗАКРПА) верзију када додате уназад компатибилне исправке bug-ова (грешака) + +Додатне ознаке за pre-release (предиздања) и метаподатке build-а (израде) доступне су као проширења +у формату MAJOR.MINOR.PATCH. + +Увод +------------ + +У свету управљања софтвером постоји ужасно место које називамо +„пакао зависности“. Како ваш систем расте и што више пакета +интегришете у свој софтвер, већа је вероватноћа да ћете се наћи +у овом стању дубоког очаја. + +У системима са мноштвом зависности, објављивање нових верзија пакета може брзо +постати кошмар. Ако су спецификације зависности сувише строге, налазите се у опасности +од закључавања верзије (немогућност надоградње пакета без неопходне +објаве нове верзије сваког зависног пакета). Такође, ако су спецификације зависности +исувише лабаве, неизбежно ће вас довести у ситуацију верзијског промискуитета +(под претпоставком компатибилности са више будућих верзија него што је разумно). +Пакао зависности је ситуација у којој се налазите када закључавање верзије и/или +верзијски промискуитет спречавају једноставно и безбедно напредовање пројекта. + +Као решење овог проблема, предлажемо једноставан скуп правила и +захтева који диктирају како се бројеви верзија додељују и инкрементирају. +Ова правила су заснована, али нису нужно ограничена на већ постојеће и широко +распрострањене уобичајене праксе које се користе у closed и open-source софтверу. +Како би овај систем функционисао, неопходно је прво објавити public (јавни) API. +Можемо то применити у документацији или у самом коду. У сваком случају, важно је да +API буде јасан и прецизан. Једном кад идентификујемо јавни API, измене преносимо +кроз спецификоване инкрементације броја верзије. +Размотримо формат верзије X.Y.Z (Major.Minor.Patch). Исправке bug-ова (грешака) који +не утичу на API инкрементирају patch (закрпа) верзију, уназад компатибилне промене +API-ја инкрементирају minor (мању) верзију, а уназад некомпатибилне промене +API-ја инкрементирају major (главну) верзију. + +Овај систем називамо „Семантичко Верзионисање“. Према овој шеми, бројеви верзија +и начин на који се мењају дају информације о коду који се налази под датом +верзијом, као и шта се мењало од једне верзије до друге. + +Спецификација Семантичког Верзионисања (SemVer) +------------------------------------------ + +Кључне речи "MUST" ("МОРА"), "MUST NOT" ("НЕ СМЕ"), "REQUIRED" ("НЕОПХОДНО"), "SHALL" ("ХОЋЕ"), "SHALL NOT" ("НЕЋЕ"), "SHOULD" ("ТРЕБА"), +"SHOULD NOT" ("НЕ ТРЕБА"), "RECOMMENDED" ("ПРЕПОРУЧЕНО"), "MAY" ("МОЖЕ") и "OPTIONAL" ("ОПЦИОНО") у овом документу треба +тумачити како је описано у [RFC 2119](https://tools.ietf.org/html/rfc2119). + +1. Софтвер који користи Семантичко Верзионисање MUST (МОРА) објавити public (јавни) API. +Овај API може бити декларисан у самом коду или постојати стриктно у документацији. +У сваком случају, SHOULD (ТРЕБА) да буде прецизан и свеобухватан. + +1. Нормалан број верзије MUST (МОРА) бити у формату X.Y.Z где су X, Y и Z +не-негативни цели бројеви који MUST NOT (НЕ СМЕЈУ) почињати са нулом. X означава +главну верзију, Y мању верзију, а Z закрпу. +Сваки елемент MUST (МОРА) се нумерички инкрементирати. На пример: 1.9.0 -> 1.10.0 -> 1.11.0. + +1. Једном кад је верзионисани пакет објављен, садржај те верзије MUST NOT (НЕ СМЕ) +се мењати. Свака измена MUST (МОРА) се објавити као нова верзија. + +1. Major (главна) верзија нула (0.y.z) је за иницијални развој. Било шта се MAY (МОЖЕ) мењати +у сваком тренутку. Тај public (јавни) API SHOULD NOT (НЕ ТРЕБА) се сматрати стабилним. + +1. Верзија 1.0.0 дефинише public (јавни) API. Начин на који ће се број верзије +инкрементирати након ове објаве зависи од овог public (јавног) API-ја +и измена на њему. + +1. Patch (закрпа) верзија Z (x.y.Z | x > 0) MUST (МОРА) се инкрементирати само када се додају уназад компатибилне исправке bug-ова (грешака). Исправке bug-ова (грешака) су +дефинисане као интерне промене које исправљају неправилно понашање. + +1. Minor (мања) верзија Y (x.Y.z | x > 0) MUST (МОРА) се инкрементирати ако је нова уназад +компатибилна функционалност уведена у јавни API. MUST (МОРА) се +инкрементирати када се нека од функционалности API-ја означи као deprecated (застарела). +MAY (МОЖЕ) бити инкрементирана уколико се уведу субстанцијално нове функционалности +или побољшања у оквиру приватног кода. MAY (МОЖЕ) укључивати patch (закрпа) промене. +Patch (закрпа) верзија MUST (МОРА) се ресетовати на 0 када се minor (мања) верзија инкрементира. + +1. Major (главна) верзија X (X.y.z | X > 0) MUST (МОРА) се инкрементирати ако се уназад +некомпатибилне промене уводе у јавни API. MAY (МОЖЕ) укључивати и minor (мање) +и patch (закрпа) промене. Patch (закрпа) и minor (мање) верзије MUST (МОРА) да се ресетују +на 0 када се major (главна) верзија инкрементира. + +1. Верзија pre-release (предиздања) MAY (МОЖЕ) бити означена додавањем hyphen-а (повлаке) +и низа идентификатора одвојених тачком непосредно након patch (закрпа) верзије. +Идентификатори MUST (МОРАЈУ) садржати само ASCII алфанумеричке знакове и повлаке +[0-9A-Za-z-]. Идентификатори MUST NOT (НЕ СМЕЈУ) бити празни. Нумерички идентификатори +MUST NOT (НЕ СМЕЈУ) почињати нулом. Верзије предиздања имају нижи приоритет од +повезане нормалне верзије. Верзија предиздања означава да је +верзија нестабилна и да можда неће бити задовољени +предвиђени захтеви компатибилности као што је означено њеном +повезаном нормалном верзијом. Примери: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, +1.0.0-x.7.z.92, 1.0.0-x-y-z.\-\-. + +1. Метаподаци build-а (израде) MAY (МОГУ) бити означени додавањем плус знака и низа +идентификатора одвојених тачком непосредно након patch (закрпе) или верзије предиздања. +Идентификатори MUST (МОРАЈУ) садржати само ASCII алфанумеричке знакове и повлаке +[0-9A-Za-z-]. Идентификатори MUST NOT (НЕ СМЕЈУ) бити празни. Метаподаци build-а (израде) MUST (МОРАЈУ) +се занемарити приликом одређивања приоритета верзије. Две верзије које се разликују +само у метаподацима build-а (израде), имају исти приоритет. Примери: 1.0.0-alpha+001, 1.0.0+20130313144700, +1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3\-\-\-\-117B344092BD. + +1. Приоритет се односи на начин којим се верзије у међусобно пореде. + + 1. Приоритет се MUST (МОРА) израчунати раздвајањем верзије на major (главну), + minor (мању), patch (закрпу) и идентификаторе предиздања (метаподаци + build-а (израде) немају улогу у одређивању приоритета). + + 1. Приоритет се одређује првом разликом када се упоређује сваки од идентификатора + са лева на десно: Major (главна), minor (мања) и patch (закрпа) + верзије се увек упоређују бројчано. + + Пример: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. + + 1. Када су major (главна), minor (мања) и patch (закрпа) једнаке, верзија предиздања + има нижи приоритет од нормалне верзије: + + Пример: 1.0.0-alpha < 1.0.0. + + 1. Приоритет између две верзије предиздања са једнаком major (главном), minor (мањом) и + patch (закрпа) верзијом MUST (МОРА) бити одређен упоређивањем сваког идентификатора одвојеног тачкама + са лева на десно док се не пронађе разлика на следећи начин: + + 1. Идентификатори који се састоје само од цифара упоређују се нумерички. + + 1. Идентификатори са словима или повлакама се упоређују лексички у ASCII + поретку. + + 1. Нумерички идентификатори увек имају нижи приоритет од ненумеричких + идентификатора. + + 1. Већи скуп ознака предиздања има виши приоритет од мањег скупа + ако су сви претходни идентификатори једнаки. + + Пример: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < + 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. + +Бакус–Наурова форма за валидне SemVer верзије +-------------------------------------------------- +``` + ::= + | "-" + | "+" + | "-" "+" + + ::= "." "." + + ::= + + ::= + + ::= + + ::= + + ::= + | "." + + ::= + + ::= + | "." + + ::= + | + + ::= + | + + ::= + | + | + | + + ::= "0" + | + | + + ::= + | + + ::= + | + + ::= + | "-" + + ::= + | + + ::= "0" + | + + ::= "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" + + ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" + | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" + | "U" | "V" | "W" | "X" | "Y" | "Z" | "a" | "b" | "c" | "d" + | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" + | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" + | "y" | "z" +``` + +Зашто користити Семантичко Верзионисање? +---------------------------- + +Ово није нова нити револуционарна идеја. Тачније, вероватно већ радите нешто +врло слично. Проблем је што нешто "слично" није довољно добро. Без +усаглашености са неком врстом формалне спецификације, бројеви верзија су +у суштини бескорисни за управљање зависностима. Давањем имена и јасних +дефиниција горе наведених идеја, постаје лако пренети своје намере +корисницима вашег софтвера. Једном када су ове намере јасне, коначно је могуће +направити флексибилне (али, не превише флексибилне) спецификације зависности. + +Једноставан пример може показати како пакао зависности уз Семантичко Верзионисање +остаје ствар прошлости. Замислите library (библиотеку) под називом "Vatrogasno_vozilo". +Неопходан јој је Семантичко Верзионисани пакет под називом "Merdevine." У тренутку креирања Vatrogasno_vozilo, +Merdevine су у верзији 3.1.0. Пошто Vatrogasno_vozilo користи неке функције +првобитно уведене у 3.1.0, можете безбедно спецификовати зависност од Merdevine +као већу или једнаку од 3.1.0, али мању од 4.0.0. Сада, када +Merdevine верзије 3.1.1 и 3.2.0 постану доступне, можете их унети у свој систем +управљања пакетима и бити сигурни да ће бити компатибилни са постојећим +зависним софтвером. + +Као одговоран програмер, ви ћете, наравно, желети да верификујете да ли +upgrade (надградње) пакета функционишу како је наведено. Стварни свет је махом неуређено место; +не можемо ништа урадити поводом тога сем да будемо опрезни. Оно што можемо учинити +је да усвојимо Семантичко Верзионисање које нам пружа разуман начин за објављивање и +надоградњу пакета, без потребе за покретањем нових верзија зависних пакета, +штедећи време и труд. + +Ако вам ово звучи пожељно, све што је потребно урадити да бисте почели да користите +Семантичко Верзионисање је да се декларишете као корисник и да потом следите правила. +Повежите овај сајт са својим README фајлом како би и други били свесни правила +и имали користи од њих. + +FAQ +--- + +### Како се носити са ревизијама 0.y.z у иницијалној фази развоја? + +Најједноставнији начин је да започнете иницијални развој објавом верзије 0.1.0 +и потом инкрементирате minor (мању) верзију за свако следеће издање. + +### Како да знам када треба објавити верзију 1.0.0? + +Ако се софтвер користи у продукцији, већ би вероватно требао бити +1.0.0. Ако већ имате стабилни API од којег корисници зависе, верзија би требала +бити 1.0.0. Уколико сте прилично забринути око компатибилности уназад, софтвер +би већ требао бити објављен под верзијом 1.0.0. + +### Зар ово не обесхрабрује рапидан развој и брзу итерацију? + +Major (главна) верзија нула је заправо предодређена рапидном развоју. Ако мењате API +сваки дан, требали би остати на верзији 0.y.z или на посебној грани за развој +радити на следећој major (главној) верзији. + +### Уколико и најситније уназад некомпатибилне измене у јавном API-ју захтевају увећавање major (главне) верзије, нећу ли врло брзо доћи до верзије 42.0.0? + +Ово је питање одговорног развоја и предвиђања. У софтвер +који има пуно зависног кода, некомпатибилне измене не треба +олако уводити. Трошкови надоградње могу бити значајни. +Ако морате повећати major (главну) верзију како бисте објавили верзију +са некомпатибилним изменама, морате размислити о утицају тих измена и +проценити однос укључених трошкова и користи. + +### Документација целокупног јавног API-ја захтева превише посла! + +Ваша одговорност као професионалног програмера је да правилно документујете +софтвер који је намењен корисницима. Управљање сложеношћу софтвера је +изузетно важан део одржавања ефикасности пројекта, а то је тешко урадити ако +нико не зна како да користи софтвер нити које методе може безбедно позвати. +Дугорочно, Семантичко Верзионисање и инсистирање на квалитетно дефинисаном +API-ју омогућиће да сви и све ради глатко. + +### Шта уколико случајно објавим уназад некомпатибилне измене као minor (мању) верзију? + +Чим приметите да сте прекршили спецификације Семантичког Верзионисања, +исправите грешку и објавите нову minor (мању) верзију која исправља проблем и +враћа компатибилност уназад. Чак и у таквим условима, није прихватљиво +модификовати верзионисане објаве. Ако је прикладно, +документујте верзију која крши спецификацију и обавестите кориснике +како би били свесни тога. + +### Шта учинити уколико изменим сопствене зависности без промене јавног API-ja? + +Такве измене сматрамо компатибилним јер не утичу на јавни API. +Софтвер који експлицитно зависи од истих зависности као и ваш сопствени пакет, +треба имати властите спецификације зависности, а аутор ће приметити евентуалне +конфликте. Да ли је промена на нивоу patch (закрпа) или minor (мање) верзије +зависи од тога да ли сте ажурирали своје зависности као исправке +bug-ова (грешака) или сте их увели као нове функционалности. У другом случају +можемо очекивати и додатни код, при чему се очигледно ради о инкременту minor (мање) верзије. + +### Шта уколико случајно изменим јавни API на начин који не одговара измени броја верзије (нпр. уведем некомпатибилну major (главну) измену у оквиру patch-а (закрпе))? + +Користите своју најбољу процену. Ако имате велики број корисника на које ће +промена јавног API-ја на жељено понашање значајно утицати, +најбоље је да објавите major (главну) верзију, иако би се исправак +могао сматрати patch-ом (закрпом). Запамтите, сврха Семантичког Верзионисања +је преношење значења путем измене броја верзије. Ако су такве +измене важне за ваше кориснике, користите број верзије да бисте их информисали. + +### Како поступати са deprecating (застарелим) функционалностима? + +Постојеће функционалности које застаревају саставни су део развоја софтвера и +често су неопходне како би развој напредовао. Кад означавате део јавног API-ја +као deprecated (застарели), потребно је пратити две ствари: (1) ажурирати документацију +како бисте информисали кориснике, (2) објавити нову minor (мању) верзију са дефинисаним +deprecated (застарелим) деловима софтвера. Пре него што потпуно уклоните функционалност +у новој major (главној) верзији, потребно је издати барем једну minor (мању) верзију која +садржи deprecated (застареле) делове, како би корисници несметано прешли на нову верзију API-ја. + +### Има ли SemVer ограничење за величину стринга верзије? + +Не, али процените сами. Стринг верзије од 255 знакова је вероватно претеран, +на пример. Такође, неки системи могу имати своја ограничења +величине стринга. + +### Да ли је "v1.2.3" семантичка верзија? + +Не, "v1.2.3" није семантичка верзија. Међутим, додавање префикса "v" на семантичку +верзију је уобичајен начин (на енглеском) да се назначи да је то број верзије. +Скраћење "version" на "v" се често види у контроли верзија. Пример: +`git tag v1.2.3 -m "Release version 1.2.3"`, где је "v1.2.3" назив +tag-а (ознаке), а семантичка верзија је "1.2.3". + +### Да ли постоји предложени регуларни израз (RegEx) за проверу SemVer стринга? + +Постоје два. Један са именованим групама за оне системе који их подржавају +(PCRE [Perl Compatible Regular Expressions (Perl компатибилни регуларни изрази), тј. Perl, PHP и R], Python +и Go). + +Погледајте: + +``` +^(?P0|[1-9]\d*)\.(?P0|[1-9]\d*)\.(?P0|[1-9]\d*)(?:-(?P(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ +``` + +И други са нумерисаним групама (znači cg1 = major (главна), cg2 = minor (мања), +cg3 = patch (закрпа), cg4 = prerelease (предиздање) и cg5 = buildmetadata (метаподаци)) који су компатибилни +sa ECMA Script (JavaScript), PCRE [Perl Compatible Regular Expressions (Perl компатибилни регуларни изрази), +тј. Perl, PHP и R], Python и Go. + +Погледајте: + +``` +^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ +``` + +О пројекту +----- + +Аутор спецификације Семантичког Верзионисања је [Tom +Preston-Werner](https://tom.preston-werner.com), проналазач Gravatar-а +и суоснивач GitHub-а. + +Ако желите оставити повратне информације, молимо [отворите issue на +GitHub-у](https://github.com/semver/semver/issues). + +Лиценца +------- + +[Creative Commons ― CC BY 3.0](https://creativecommons.org/licenses/by/3.0/) From 73c97fefe1ec09759d321c8e1f6dc8694fcbe805 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rado=C5=A1=20Mili=C4=87ev?= <40705899+rammba@users.noreply.github.com> Date: Sun, 31 Aug 2025 16:17:24 +0200 Subject: [PATCH 2/4] Update and rename Serbian latin files sr => sr-Latn --- lang/sr-Latn/index.md | 377 ++++++++++++++++++++++++++++++++++++ lang/sr-Latn/spec/v2.0.0.md | 377 ++++++++++++++++++++++++++++++++++++ lang/sr/index.md | 309 ----------------------------- lang/sr/spec/v2.0.0.md | 309 ----------------------------- 4 files changed, 754 insertions(+), 618 deletions(-) create mode 100644 lang/sr-Latn/index.md create mode 100644 lang/sr-Latn/spec/v2.0.0.md delete mode 100644 lang/sr/index.md delete mode 100644 lang/sr/spec/v2.0.0.md diff --git a/lang/sr-Latn/index.md b/lang/sr-Latn/index.md new file mode 100644 index 00000000..6cabbfd4 --- /dev/null +++ b/lang/sr-Latn/index.md @@ -0,0 +1,377 @@ +--- +title: Semantičko Verzionisanje 2.0.0 +language: sr-Latn +author: Aleksandar Marinković, Radoš Milićev +--- + +Semantičko Verzionisanje 2.0.0 +============================== + +Sažetak +------- + +Za dati broj verzije MAJOR.MINOR.PATCH, inkrementirajte: + +1. MAJOR (GLAVNU) verziju kada unesete nekompatibilne izmene API-ja +1. MINOR (MANJU) verziju kada dodate unazad kompatibilnu funkcionalnost +1. PATCH (ZAKRPA) verziju kada dodate unazad kompatibilne ispravke bug-ova (grešaka) + +Dodatne oznake za pre-release (predizdanja) i metapodatke build-a (izrade) dostupne su kao proširenja +u formatu MAJOR.MINOR.PATCH. + +Uvod +------------ + +U svetu upravljanja softverom postoji užasno mesto koje nazivamo +„pakao zavisnosti“. Kako vaš sistem raste i što više paketa +integrišete u svoj softver, veća je verovatnoća da ćete se naći +u ovom stanju dubokog očaja. + +U sistemima sa mnoštvom zavisnosti, objavljivanje novih verzija paketa može brzo +postati košmar. Ako su specifikacije zavisnosti suviše stroge, nalazite se u opasnosti +od zaključavanja verzije (nemogućnost nadogradnje paketa bez neophodne +objave nove verzije svakog zavisnog paketa). Takođe, ako su specifikacije zavisnosti +isuviše labave, neizbežno će vas dovesti u situaciju verzijskog promiskuiteta +(pod pretpostavkom kompatibilnosti sa više budućih verzija nego što je razumno). +Pakao zavisnosti je situacija u kojoj se nalazite kada zaključavanje verzije i/ili +verzijski promiskuitet sprečavaju jednostavno i bezbedno napredovanje projekta. + +Kao rešenje ovog problema, predlažemo jednostavan skup pravila i +zahteva koji diktiraju kako se brojevi verzija dodeljuju i inkrementiraju. +Ova pravila su zasnovana, ali nisu nužno ograničena na već postojeće i široko +rasprostranjene uobičajene prakse koje se koriste u closed i open-source softveru. +Kako bi ovaj sistem funkcionisao, neophodno je prvo objaviti public (javni) API. +Možemo to primeniti u dokumentaciji ili u samom kodu. U svakom slučaju, važno je da +API bude jasan i precizan. Jednom kad identifikujemo javni API, izmene prenosimo +kroz specifikovane inkrementacije broja verzije. +Razmotrimo format verzije X.Y.Z (Major.Minor.Patch). Ispravke bug-ova (grešaka) koji +ne utiču na API inkrementiraju patch (zakrpa) verziju, unazad kompatibilne promene +API-ja inkrementiraju minor (manju) verziju, a unazad nekompatibilne promene +API-ja inkrementiraju major (glavnu) verziju. + +Ovaj sistem nazivamo „Semantičko Verzionisanje“. Prema ovoj šemi, brojevi verzija +i način na koji se menjaju daju informacije o kodu koji se nalazi pod datom +verzijom, kao i šta se menjalo od jedne verzije do druge. + +Specifikacija Semantičkog Verzionisanja (SemVer) +------------------------------------------ + +Ključne reči "MUST" ("MORA"), "MUST NOT" ("NE SME"), "REQUIRED" ("NEOPHODNO"), "SHALL" ("HOĆE"), "SHALL NOT" ("NEĆE"), "SHOULD" ("TREBA"), +"SHOULD NOT" ("NE TREBA"), "RECOMMENDED" ("PREPORUČENO"), "MAY" ("MOŽE") i "OPTIONAL" ("OPCIONO") u ovom dokumentu treba +tumačiti kako je opisano u [RFC 2119](https://tools.ietf.org/html/rfc2119). + +1. Softver koji koristi Semantičko Verzionisanje MUST (MORA) objaviti public (javni) API. +Ovaj API može biti deklarisan u samom kodu ili postojati striktno u dokumentaciji. +U svakom slučaju, SHOULD (TREBA) da bude precizan i sveobuhvatan. + +1. Normalan broj verzije MUST (MORA) biti u formatu X.Y.Z gde su X, Y i Z +ne-negativni celi brojevi koji MUST NOT (NE SMEJU) počinjati sa nulom. X označava +glavnu verziju, Y manju verziju, a Z zakrpu. +Svaki element MUST (MORA) se numerički inkrementirati. Na primer: 1.9.0 -> 1.10.0 -> 1.11.0. + +1. Jednom kad je verzionisani paket objavljen, sadržaj te verzije MUST NOT (NE SME) +se menjati. Svaka izmena MUST (MORA) se objaviti kao nova verzija. + +1. Major (glavna) verzija nula (0.y.z) je za inicijalni razvoj. Bilo šta se MAY (MOŽE) menjati +u svakom trenutku. Taj public (javni) API SHOULD NOT (NE TREBA) se smatrati stabilnim. + +1. Verzija 1.0.0 definiše public (javni) API. Način na koji će se broj verzije +inkrementirati nakon ove objave zavisi od ovog public (javnog) API-ja +i izmena na njemu. + +1. Patch (zakrpa) verzija Z (x.y.Z | x > 0) MUST (MORA) se inkrementirati samo kada se dodaju unazad kompatibilne ispravke bug-ova (grešaka). Ispravke bug-ova (grešaka) su +definisane kao interne promene koje ispravljaju nepravilno ponašanje. + +1. Minor (manja) verzija Y (x.Y.z | x > 0) MUST (MORA) se inkrementirati ako je nova unazad +kompatibilna funkcionalnost uvedena u javni API. MUST (MORA) se +inkrementirati kada se neka od funkcionalnosti API-ja označi kao deprecated (zastarela). +MAY (MOŽE) biti inkrementirana ukoliko se uvedu substancijalno nove funkcionalnosti +ili poboljšanja u okviru privatnog koda. MAY (MOŽE) uključivati patch (zakrpa) promene. +Patch (zakrpa) verzija MUST (MORA) se resetovati na 0 kada se minor (manja) verzija inkrementira. + +1. Major (glavna) verzija X (X.y.z | X > 0) MUST (MORA) se inkrementirati ako se unazad +nekompatibilne promene uvode u javni API. MAY (MOŽE) uključivati i minor (manje) +i patch (zakrpa) promene. Patch (zakrpa) i minor (manje) verzije MUST (MORA) da se resetuju +na 0 kada se major (glavna) verzija inkrementira. + +1. Verzija pre-release (predizdanja) MAY (MOŽE) biti označena dodavanjem hyphen-a (povlake) +i niza identifikatora odvojenih tačkom neposredno nakon patch (zakrpa) verzije. +Identifikatori MUST (MORAJU) sadržati samo ASCII alfanumeričke znakove i povlake +[0-9A-Za-z-]. Identifikatori MUST NOT (NE SMEJU) biti prazni. Numerički identifikatori +MUST NOT (NE SMEJU) počinjati nulom. Verzije predizdanja imaju niži prioritet od +povezane normalne verzije. Verzija predizdanja označava da je +verzija nestabilna i da možda neće biti zadovoljeni +predviđeni zahtevi kompatibilnosti kao što je označeno njenom +povezanom normalnom verzijom. Primeri: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, +1.0.0-x.7.z.92, 1.0.0-x-y-z.\-\-. + +1. Metapodaci build-a (izrade) MAY (MOGU) biti označeni dodavanjem plus znaka i niza +identifikatora odvojenih tačkom neposredno nakon patch (zakrpe) ili verzije predizdanja. +Identifikatori MUST (MORAJU) sadržati samo ASCII alfanumeričke znakove i povlake +[0-9A-Za-z-]. Identifikatori MUST NOT (NE SMEJU) biti prazni. Metapodaci build-a (izrade) MUST (MORAJU) +se zanemariti prilikom određivanja prioriteta verzije. Dve verzije koje se razlikuju +samo u metapodacima build-a (izrade), imaju isti prioritet. Primeri: 1.0.0-alpha+001, 1.0.0+20130313144700, +1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3\-\-\-\-117B344092BD. + +1. Prioritet se odnosi na način kojim se verzije u međusobno porede. + + 1. Prioritet se MUST (MORA) izračunati razdvajanjem verzije na major (glavnu), + minor (manju), patch (zakrpu) i identifikatore predizdanja (metapodaci + build-a (izrade) nemaju ulogu u određivanju prioriteta). + + 1. Prioritet se određuje prvom razlikom kada se upoređuje svaki od identifikatora + sa leva na desno: Major (glavna), minor (manja) i patch (zakrpa) + verzije se uvek upoređuju brojčano. + + Primer: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. + + 1. Kada su major (glavna), minor (manja) i patch (zakrpa) jednake, verzija predizdanja + ima niži prioritet od normalne verzije: + + Primer: 1.0.0-alpha < 1.0.0. + + 1. Prioritet između dve verzije predizdanja sa jednakom major (glavnom), minor (manjom) i + patch (zakrpa) verzijom MUST (MORA) biti određen upoređivanjem svakog identifikatora odvojenog tačkama + sa leva na desno dok se ne pronađe razlika na sledeći način: + + 1. Identifikatori koji se sastoje samo od cifara upoređuju se numerički. + + 1. Identifikatori sa slovima ili povlakama se upoređuju leksički u ASCII + poretku. + + 1. Numerički identifikatori uvek imaju niži prioritet od nenumeričkih + identifikatora. + + 1. Veći skup oznaka predizdanja ima viši prioritet od manjeg skupa + ako su svi prethodni identifikatori jednaki. + + Primer: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < + 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. + +Bakus–Naurova forma za validne SemVer verzije +-------------------------------------------------- +``` + ::= + | "-" + | "+" + | "-" "+" + + ::= "." "." + + ::= + + ::= + + ::= + + ::= + + ::= + | "." + + ::= + + ::= + | "." + + ::= + | + + ::= + | + + ::= + | + | + | + + ::= "0" + | + | + + ::= + | + + ::= + | + + ::= + | "-" + + ::= + | + + ::= "0" + | + + ::= "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" + + ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" + | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" + | "U" | "V" | "W" | "X" | "Y" | "Z" | "a" | "b" | "c" | "d" + | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" + | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" + | "y" | "z" +``` + +Zašto koristiti Semantičko Verzionisanje? +---------------------------- + +Ovo nije nova niti revolucionarna ideja. Tačnije, verovatno već radite nešto +vrlo slično. Problem je što nešto "slično" nije dovoljno dobro. Bez +usaglašenosti sa nekom vrstom formalne specifikacije, brojevi verzija su +u suštini beskorisni za upravljanje zavisnostima. Davanjem imena i jasnih +definicija gore navedenih ideja, postaje lako preneti svoje namere +korisnicima vašeg softvera. Jednom kada su ove namere jasne, konačno je moguće +napraviti fleksibilne (ali, ne previše fleksibilne) specifikacije zavisnosti. + +Jednostavan primer može pokazati kako pakao zavisnosti uz Semantičko Verzionisanje +ostaje stvar prošlosti. Zamislite library (biblioteku) pod nazivom "Vatrogasno_vozilo". +Neophodan joj je Semantičko Verzionisani paket pod nazivom "Merdevine." U trenutku kreiranja Vatrogasno_vozilo, +Merdevine su u verziji 3.1.0. Pošto Vatrogasno_vozilo koristi neke funkcije +prvobitno uvedene u 3.1.0, možete bezbedno specifikovati zavisnost od Merdevine +kao veću ili jednaku od 3.1.0, ali manju od 4.0.0. Sada, kada +Merdevine verzije 3.1.1 i 3.2.0 postanu dostupne, možete ih uneti u svoj sistem +upravljanja paketima i biti sigurni da će biti kompatibilni sa postojećim +zavisnim softverom. + +Kao odgovoran programer, vi ćete, naravno, želeti da verifikujete da li +upgrade (nadgradnje) paketa funkcionišu kako je navedeno. Stvarni svet je mahom neuređeno mesto; +ne možemo ništa uraditi povodom toga sem da budemo oprezni. Ono što možemo učiniti +je da usvojimo Semantičko Verzionisanje koje nam pruža razuman način za objavljivanje i +nadogradnju paketa, bez potrebe za pokretanjem novih verzija zavisnih paketa, +štedeći vreme i trud. + +Ako vam ovo zvuči poželjno, sve što je potrebno uraditi da biste počeli da koristite +Semantičko Verzionisanje je da se deklarišete kao korisnik i da potom sledite pravila. +Povežite ovaj sajt sa svojim README fajlom kako bi i drugi bili svesni pravila +i imali koristi od njih. + +FAQ +--- + +### Kako se nositi sa revizijama 0.y.z u inicijalnoj fazi razvoja? + +Najjednostavniji način je da započnete inicijalni razvoj objavom verzije 0.1.0 +i potom inkrementirate minor (manju) verziju za svako sledeće izdanje. + +### Kako da znam kada treba objaviti verziju 1.0.0? + +Ako se softver koristi u produkciji, već bi verovatno trebao biti +1.0.0. Ako već imate stabilni API od kojeg korisnici zavise, verzija bi trebala +biti 1.0.0. Ukoliko ste prilično zabrinuti oko kompatibilnosti unazad, softver +bi već trebao biti objavljen pod verzijom 1.0.0. + +### Zar ovo ne obeshrabruje rapidan razvoj i brzu iteraciju? + +Major (glavna) verzija nula je zapravo predodređena rapidnom razvoju. Ako menjate API +svaki dan, trebali bi ostati na verziji 0.y.z ili na posebnoj grani za razvoj +raditi na sledećoj major (glavnoj) verziji. + +### Ukoliko i najsitnije unazad nekompatibilne izmene u javnom API-ju zahtevaju uvećavanje major (glavne) verzije, neću li vrlo brzo doći do verzije 42.0.0? + +Ovo je pitanje odgovornog razvoja i predviđanja. U softver +koji ima puno zavisnog koda, nekompatibilne izmene ne treba +olako uvoditi. Troškovi nadogradnje mogu biti značajni. +Ako morate povećati major (glavnu) verziju kako biste objavili verziju +sa nekompatibilnim izmenama, morate razmisliti o uticaju tih izmena i +proceniti odnos uključenih troškova i koristi. + +### Dokumentacija celokupnog javnog API-ja zahteva previše posla! + +Vaša odgovornost kao profesionalnog programera je da pravilno dokumentujete +softver koji je namenjen korisnicima. Upravljanje složenošću softvera je +izuzetno važan deo održavanja efikasnosti projekta, a to je teško uraditi ako +niko ne zna kako da koristi softver niti koje metode može bezbedno pozvati. +Dugoročno, Semantičko Verzionisanje i insistiranje na kvalitetno definisanom +API-ju omogućiće da svi i sve radi glatko. + +### Šta ukoliko slučajno objavim unazad nekompatibilne izmene kao minor (manju) verziju? + +Čim primetite da ste prekršili specifikacije Semantičkog Verzionisanja, +ispravite grešku i objavite novu minor (manju) verziju koja ispravlja problem i +vraća kompatibilnost unazad. Čak i u takvim uslovima, nije prihvatljivo +modifikovati verzionisane objave. Ako je prikladno, +dokumentujte verziju koja krši specifikaciju i obavestite korisnike +kako bi bili svesni toga. + +### Šta učiniti ukoliko izmenim sopstvene zavisnosti bez promene javnog API-ja? + +Takve izmene smatramo kompatibilnim jer ne utiču na javni API. +Softver koji eksplicitno zavisi od istih zavisnosti kao i vaš sopstveni paket, +treba imati vlastite specifikacije zavisnosti, a autor će primetiti eventualne +konflikte. Da li je promena na nivou patch (zakrpa) ili minor (manje) verzije +zavisi od toga da li ste ažurirali svoje zavisnosti kao ispravke +bug-ova (grešaka) ili ste ih uveli kao nove funkcionalnosti. U drugom slučaju +možemo očekivati i dodatni kod, pri čemu se očigledno radi o inkrementu minor (manje) verzije. + +### Šta ukoliko slučajno izmenim javni API na način koji ne odgovara izmeni broja verzije (npr. uvedem nekompatibilnu major (glavnu) izmenu u okviru patch-a (zakrpe))? + +Koristite svoju najbolju procenu. Ako imate veliki broj korisnika na koje će +promena javnog API-ja na željeno ponašanje značajno uticati, +najbolje je da objavite major (glavnu) verziju, iako bi se ispravak +mogao smatrati patch-om (zakrpom). Zapamtite, svrha Semantičkog Verzionisanja +je prenošenje značenja putem izmene broja verzije. Ako su takve +izmene važne za vaše korisnike, koristite broj verzije da biste ih informisali. + +### Kako postupati sa deprecating (zastarelim) funkcionalnostima? + +Postojeće funkcionalnosti koje zastarevaju sastavni su deo razvoja softvera i +često su neophodne kako bi razvoj napredovao. Kad označavate deo javnog API-ja +kao deprecated (zastareli), potrebno je pratiti dve stvari: (1) ažurirati dokumentaciju +kako biste informisali korisnike, (2) objaviti novu minor (manju) verziju sa definisanim +deprecated (zastarelim) delovima softvera. Pre nego što potpuno uklonite funkcionalnost +u novoj major (glavnoj) verziji, potrebno je izdati barem jednu minor (manju) verziju koja +sadrži deprecated (zastarele) delove, kako bi korisnici nesmetano prešli na novu verziju API-ja. + +### Ima li SemVer ograničenje za veličinu stringa verzije? + +Ne, ali procenite sami. String verzije od 255 znakova je verovatno preteran, +na primer. Takođe, neki sistemi mogu imati svoja ograničenja +veličine stringa. + +### Da li je "v1.2.3" semantička verzija? + +Ne, "v1.2.3" nije semantička verzija. Međutim, dodavanje prefiksa "v" na semantičku +verziju je uobičajen način (na engleskom) da se naznači da je to broj verzije. +Skraćenje "version" na "v" se često vidi u kontroli verzija. Primer: +`git tag v1.2.3 -m "Release version 1.2.3"`, gde je "v1.2.3" naziv +tag-a (oznake), a semantička verzija je "1.2.3". + +### Da li postoji predloženi regularni izraz (RegEx) za proveru SemVer stringa? + +Postoje dva. Jedan sa imenovanim grupama za one sisteme koji ih podržavaju +(PCRE [Perl Compatible Regular Expressions (Perl kompatibilni regularni izrazi), tj. Perl, PHP i R], Python +i Go). + +Pogledajte: + +``` +^(?P0|[1-9]\d*)\.(?P0|[1-9]\d*)\.(?P0|[1-9]\d*)(?:-(?P(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ +``` + +I drugi sa numerisanim grupama (znači cg1 = major (glavna), cg2 = minor (manja), +cg3 = patch (zakrpa), cg4 = prerelease (predizdanje) i cg5 = buildmetadata (metapodaci)) koji su kompatibilni +sa ECMA Script (JavaScript), PCRE [Perl Compatible Regular Expressions (Perl kompatibilni regularni izrazi), +tj. Perl, PHP i R], Python i Go. + +Pogledajte: + +``` +^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ +``` + +O projektu +----- + +Autor specifikacije Semantičkog Verzionisanja je [Tom +Preston-Werner](https://tom.preston-werner.com), pronalazač Gravatar-a +i suosnivač GitHub-a. + +Ako želite ostaviti povratne informacije, molimo [otvorite issue na +GitHub-u](https://github.com/semver/semver/issues). + +Licenca +------- + +[Creative Commons ― CC BY 3.0](https://creativecommons.org/licenses/by/3.0/) diff --git a/lang/sr-Latn/spec/v2.0.0.md b/lang/sr-Latn/spec/v2.0.0.md new file mode 100644 index 00000000..6cabbfd4 --- /dev/null +++ b/lang/sr-Latn/spec/v2.0.0.md @@ -0,0 +1,377 @@ +--- +title: Semantičko Verzionisanje 2.0.0 +language: sr-Latn +author: Aleksandar Marinković, Radoš Milićev +--- + +Semantičko Verzionisanje 2.0.0 +============================== + +Sažetak +------- + +Za dati broj verzije MAJOR.MINOR.PATCH, inkrementirajte: + +1. MAJOR (GLAVNU) verziju kada unesete nekompatibilne izmene API-ja +1. MINOR (MANJU) verziju kada dodate unazad kompatibilnu funkcionalnost +1. PATCH (ZAKRPA) verziju kada dodate unazad kompatibilne ispravke bug-ova (grešaka) + +Dodatne oznake za pre-release (predizdanja) i metapodatke build-a (izrade) dostupne su kao proširenja +u formatu MAJOR.MINOR.PATCH. + +Uvod +------------ + +U svetu upravljanja softverom postoji užasno mesto koje nazivamo +„pakao zavisnosti“. Kako vaš sistem raste i što više paketa +integrišete u svoj softver, veća je verovatnoća da ćete se naći +u ovom stanju dubokog očaja. + +U sistemima sa mnoštvom zavisnosti, objavljivanje novih verzija paketa može brzo +postati košmar. Ako su specifikacije zavisnosti suviše stroge, nalazite se u opasnosti +od zaključavanja verzije (nemogućnost nadogradnje paketa bez neophodne +objave nove verzije svakog zavisnog paketa). Takođe, ako su specifikacije zavisnosti +isuviše labave, neizbežno će vas dovesti u situaciju verzijskog promiskuiteta +(pod pretpostavkom kompatibilnosti sa više budućih verzija nego što je razumno). +Pakao zavisnosti je situacija u kojoj se nalazite kada zaključavanje verzije i/ili +verzijski promiskuitet sprečavaju jednostavno i bezbedno napredovanje projekta. + +Kao rešenje ovog problema, predlažemo jednostavan skup pravila i +zahteva koji diktiraju kako se brojevi verzija dodeljuju i inkrementiraju. +Ova pravila su zasnovana, ali nisu nužno ograničena na već postojeće i široko +rasprostranjene uobičajene prakse koje se koriste u closed i open-source softveru. +Kako bi ovaj sistem funkcionisao, neophodno je prvo objaviti public (javni) API. +Možemo to primeniti u dokumentaciji ili u samom kodu. U svakom slučaju, važno je da +API bude jasan i precizan. Jednom kad identifikujemo javni API, izmene prenosimo +kroz specifikovane inkrementacije broja verzije. +Razmotrimo format verzije X.Y.Z (Major.Minor.Patch). Ispravke bug-ova (grešaka) koji +ne utiču na API inkrementiraju patch (zakrpa) verziju, unazad kompatibilne promene +API-ja inkrementiraju minor (manju) verziju, a unazad nekompatibilne promene +API-ja inkrementiraju major (glavnu) verziju. + +Ovaj sistem nazivamo „Semantičko Verzionisanje“. Prema ovoj šemi, brojevi verzija +i način na koji se menjaju daju informacije o kodu koji se nalazi pod datom +verzijom, kao i šta se menjalo od jedne verzije do druge. + +Specifikacija Semantičkog Verzionisanja (SemVer) +------------------------------------------ + +Ključne reči "MUST" ("MORA"), "MUST NOT" ("NE SME"), "REQUIRED" ("NEOPHODNO"), "SHALL" ("HOĆE"), "SHALL NOT" ("NEĆE"), "SHOULD" ("TREBA"), +"SHOULD NOT" ("NE TREBA"), "RECOMMENDED" ("PREPORUČENO"), "MAY" ("MOŽE") i "OPTIONAL" ("OPCIONO") u ovom dokumentu treba +tumačiti kako je opisano u [RFC 2119](https://tools.ietf.org/html/rfc2119). + +1. Softver koji koristi Semantičko Verzionisanje MUST (MORA) objaviti public (javni) API. +Ovaj API može biti deklarisan u samom kodu ili postojati striktno u dokumentaciji. +U svakom slučaju, SHOULD (TREBA) da bude precizan i sveobuhvatan. + +1. Normalan broj verzije MUST (MORA) biti u formatu X.Y.Z gde su X, Y i Z +ne-negativni celi brojevi koji MUST NOT (NE SMEJU) počinjati sa nulom. X označava +glavnu verziju, Y manju verziju, a Z zakrpu. +Svaki element MUST (MORA) se numerički inkrementirati. Na primer: 1.9.0 -> 1.10.0 -> 1.11.0. + +1. Jednom kad je verzionisani paket objavljen, sadržaj te verzije MUST NOT (NE SME) +se menjati. Svaka izmena MUST (MORA) se objaviti kao nova verzija. + +1. Major (glavna) verzija nula (0.y.z) je za inicijalni razvoj. Bilo šta se MAY (MOŽE) menjati +u svakom trenutku. Taj public (javni) API SHOULD NOT (NE TREBA) se smatrati stabilnim. + +1. Verzija 1.0.0 definiše public (javni) API. Način na koji će se broj verzije +inkrementirati nakon ove objave zavisi od ovog public (javnog) API-ja +i izmena na njemu. + +1. Patch (zakrpa) verzija Z (x.y.Z | x > 0) MUST (MORA) se inkrementirati samo kada se dodaju unazad kompatibilne ispravke bug-ova (grešaka). Ispravke bug-ova (grešaka) su +definisane kao interne promene koje ispravljaju nepravilno ponašanje. + +1. Minor (manja) verzija Y (x.Y.z | x > 0) MUST (MORA) se inkrementirati ako je nova unazad +kompatibilna funkcionalnost uvedena u javni API. MUST (MORA) se +inkrementirati kada se neka od funkcionalnosti API-ja označi kao deprecated (zastarela). +MAY (MOŽE) biti inkrementirana ukoliko se uvedu substancijalno nove funkcionalnosti +ili poboljšanja u okviru privatnog koda. MAY (MOŽE) uključivati patch (zakrpa) promene. +Patch (zakrpa) verzija MUST (MORA) se resetovati na 0 kada se minor (manja) verzija inkrementira. + +1. Major (glavna) verzija X (X.y.z | X > 0) MUST (MORA) se inkrementirati ako se unazad +nekompatibilne promene uvode u javni API. MAY (MOŽE) uključivati i minor (manje) +i patch (zakrpa) promene. Patch (zakrpa) i minor (manje) verzije MUST (MORA) da se resetuju +na 0 kada se major (glavna) verzija inkrementira. + +1. Verzija pre-release (predizdanja) MAY (MOŽE) biti označena dodavanjem hyphen-a (povlake) +i niza identifikatora odvojenih tačkom neposredno nakon patch (zakrpa) verzije. +Identifikatori MUST (MORAJU) sadržati samo ASCII alfanumeričke znakove i povlake +[0-9A-Za-z-]. Identifikatori MUST NOT (NE SMEJU) biti prazni. Numerički identifikatori +MUST NOT (NE SMEJU) počinjati nulom. Verzije predizdanja imaju niži prioritet od +povezane normalne verzije. Verzija predizdanja označava da je +verzija nestabilna i da možda neće biti zadovoljeni +predviđeni zahtevi kompatibilnosti kao što je označeno njenom +povezanom normalnom verzijom. Primeri: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, +1.0.0-x.7.z.92, 1.0.0-x-y-z.\-\-. + +1. Metapodaci build-a (izrade) MAY (MOGU) biti označeni dodavanjem plus znaka i niza +identifikatora odvojenih tačkom neposredno nakon patch (zakrpe) ili verzije predizdanja. +Identifikatori MUST (MORAJU) sadržati samo ASCII alfanumeričke znakove i povlake +[0-9A-Za-z-]. Identifikatori MUST NOT (NE SMEJU) biti prazni. Metapodaci build-a (izrade) MUST (MORAJU) +se zanemariti prilikom određivanja prioriteta verzije. Dve verzije koje se razlikuju +samo u metapodacima build-a (izrade), imaju isti prioritet. Primeri: 1.0.0-alpha+001, 1.0.0+20130313144700, +1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3\-\-\-\-117B344092BD. + +1. Prioritet se odnosi na način kojim se verzije u međusobno porede. + + 1. Prioritet se MUST (MORA) izračunati razdvajanjem verzije na major (glavnu), + minor (manju), patch (zakrpu) i identifikatore predizdanja (metapodaci + build-a (izrade) nemaju ulogu u određivanju prioriteta). + + 1. Prioritet se određuje prvom razlikom kada se upoređuje svaki od identifikatora + sa leva na desno: Major (glavna), minor (manja) i patch (zakrpa) + verzije se uvek upoređuju brojčano. + + Primer: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. + + 1. Kada su major (glavna), minor (manja) i patch (zakrpa) jednake, verzija predizdanja + ima niži prioritet od normalne verzije: + + Primer: 1.0.0-alpha < 1.0.0. + + 1. Prioritet između dve verzije predizdanja sa jednakom major (glavnom), minor (manjom) i + patch (zakrpa) verzijom MUST (MORA) biti određen upoređivanjem svakog identifikatora odvojenog tačkama + sa leva na desno dok se ne pronađe razlika na sledeći način: + + 1. Identifikatori koji se sastoje samo od cifara upoređuju se numerički. + + 1. Identifikatori sa slovima ili povlakama se upoređuju leksički u ASCII + poretku. + + 1. Numerički identifikatori uvek imaju niži prioritet od nenumeričkih + identifikatora. + + 1. Veći skup oznaka predizdanja ima viši prioritet od manjeg skupa + ako su svi prethodni identifikatori jednaki. + + Primer: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < + 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. + +Bakus–Naurova forma za validne SemVer verzije +-------------------------------------------------- +``` + ::= + | "-" + | "+" + | "-" "+" + + ::= "." "." + + ::= + + ::= + + ::= + + ::= + + ::= + | "." + + ::= + + ::= + | "." + + ::= + | + + ::= + | + + ::= + | + | + | + + ::= "0" + | + | + + ::= + | + + ::= + | + + ::= + | "-" + + ::= + | + + ::= "0" + | + + ::= "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" + + ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" + | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" + | "U" | "V" | "W" | "X" | "Y" | "Z" | "a" | "b" | "c" | "d" + | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" + | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" + | "y" | "z" +``` + +Zašto koristiti Semantičko Verzionisanje? +---------------------------- + +Ovo nije nova niti revolucionarna ideja. Tačnije, verovatno već radite nešto +vrlo slično. Problem je što nešto "slično" nije dovoljno dobro. Bez +usaglašenosti sa nekom vrstom formalne specifikacije, brojevi verzija su +u suštini beskorisni za upravljanje zavisnostima. Davanjem imena i jasnih +definicija gore navedenih ideja, postaje lako preneti svoje namere +korisnicima vašeg softvera. Jednom kada su ove namere jasne, konačno je moguće +napraviti fleksibilne (ali, ne previše fleksibilne) specifikacije zavisnosti. + +Jednostavan primer može pokazati kako pakao zavisnosti uz Semantičko Verzionisanje +ostaje stvar prošlosti. Zamislite library (biblioteku) pod nazivom "Vatrogasno_vozilo". +Neophodan joj je Semantičko Verzionisani paket pod nazivom "Merdevine." U trenutku kreiranja Vatrogasno_vozilo, +Merdevine su u verziji 3.1.0. Pošto Vatrogasno_vozilo koristi neke funkcije +prvobitno uvedene u 3.1.0, možete bezbedno specifikovati zavisnost od Merdevine +kao veću ili jednaku od 3.1.0, ali manju od 4.0.0. Sada, kada +Merdevine verzije 3.1.1 i 3.2.0 postanu dostupne, možete ih uneti u svoj sistem +upravljanja paketima i biti sigurni da će biti kompatibilni sa postojećim +zavisnim softverom. + +Kao odgovoran programer, vi ćete, naravno, želeti da verifikujete da li +upgrade (nadgradnje) paketa funkcionišu kako je navedeno. Stvarni svet je mahom neuređeno mesto; +ne možemo ništa uraditi povodom toga sem da budemo oprezni. Ono što možemo učiniti +je da usvojimo Semantičko Verzionisanje koje nam pruža razuman način za objavljivanje i +nadogradnju paketa, bez potrebe za pokretanjem novih verzija zavisnih paketa, +štedeći vreme i trud. + +Ako vam ovo zvuči poželjno, sve što je potrebno uraditi da biste počeli da koristite +Semantičko Verzionisanje je da se deklarišete kao korisnik i da potom sledite pravila. +Povežite ovaj sajt sa svojim README fajlom kako bi i drugi bili svesni pravila +i imali koristi od njih. + +FAQ +--- + +### Kako se nositi sa revizijama 0.y.z u inicijalnoj fazi razvoja? + +Najjednostavniji način je da započnete inicijalni razvoj objavom verzije 0.1.0 +i potom inkrementirate minor (manju) verziju za svako sledeće izdanje. + +### Kako da znam kada treba objaviti verziju 1.0.0? + +Ako se softver koristi u produkciji, već bi verovatno trebao biti +1.0.0. Ako već imate stabilni API od kojeg korisnici zavise, verzija bi trebala +biti 1.0.0. Ukoliko ste prilično zabrinuti oko kompatibilnosti unazad, softver +bi već trebao biti objavljen pod verzijom 1.0.0. + +### Zar ovo ne obeshrabruje rapidan razvoj i brzu iteraciju? + +Major (glavna) verzija nula je zapravo predodređena rapidnom razvoju. Ako menjate API +svaki dan, trebali bi ostati na verziji 0.y.z ili na posebnoj grani za razvoj +raditi na sledećoj major (glavnoj) verziji. + +### Ukoliko i najsitnije unazad nekompatibilne izmene u javnom API-ju zahtevaju uvećavanje major (glavne) verzije, neću li vrlo brzo doći do verzije 42.0.0? + +Ovo je pitanje odgovornog razvoja i predviđanja. U softver +koji ima puno zavisnog koda, nekompatibilne izmene ne treba +olako uvoditi. Troškovi nadogradnje mogu biti značajni. +Ako morate povećati major (glavnu) verziju kako biste objavili verziju +sa nekompatibilnim izmenama, morate razmisliti o uticaju tih izmena i +proceniti odnos uključenih troškova i koristi. + +### Dokumentacija celokupnog javnog API-ja zahteva previše posla! + +Vaša odgovornost kao profesionalnog programera je da pravilno dokumentujete +softver koji je namenjen korisnicima. Upravljanje složenošću softvera je +izuzetno važan deo održavanja efikasnosti projekta, a to je teško uraditi ako +niko ne zna kako da koristi softver niti koje metode može bezbedno pozvati. +Dugoročno, Semantičko Verzionisanje i insistiranje na kvalitetno definisanom +API-ju omogućiće da svi i sve radi glatko. + +### Šta ukoliko slučajno objavim unazad nekompatibilne izmene kao minor (manju) verziju? + +Čim primetite da ste prekršili specifikacije Semantičkog Verzionisanja, +ispravite grešku i objavite novu minor (manju) verziju koja ispravlja problem i +vraća kompatibilnost unazad. Čak i u takvim uslovima, nije prihvatljivo +modifikovati verzionisane objave. Ako je prikladno, +dokumentujte verziju koja krši specifikaciju i obavestite korisnike +kako bi bili svesni toga. + +### Šta učiniti ukoliko izmenim sopstvene zavisnosti bez promene javnog API-ja? + +Takve izmene smatramo kompatibilnim jer ne utiču na javni API. +Softver koji eksplicitno zavisi od istih zavisnosti kao i vaš sopstveni paket, +treba imati vlastite specifikacije zavisnosti, a autor će primetiti eventualne +konflikte. Da li je promena na nivou patch (zakrpa) ili minor (manje) verzije +zavisi od toga da li ste ažurirali svoje zavisnosti kao ispravke +bug-ova (grešaka) ili ste ih uveli kao nove funkcionalnosti. U drugom slučaju +možemo očekivati i dodatni kod, pri čemu se očigledno radi o inkrementu minor (manje) verzije. + +### Šta ukoliko slučajno izmenim javni API na način koji ne odgovara izmeni broja verzije (npr. uvedem nekompatibilnu major (glavnu) izmenu u okviru patch-a (zakrpe))? + +Koristite svoju najbolju procenu. Ako imate veliki broj korisnika na koje će +promena javnog API-ja na željeno ponašanje značajno uticati, +najbolje je da objavite major (glavnu) verziju, iako bi se ispravak +mogao smatrati patch-om (zakrpom). Zapamtite, svrha Semantičkog Verzionisanja +je prenošenje značenja putem izmene broja verzije. Ako su takve +izmene važne za vaše korisnike, koristite broj verzije da biste ih informisali. + +### Kako postupati sa deprecating (zastarelim) funkcionalnostima? + +Postojeće funkcionalnosti koje zastarevaju sastavni su deo razvoja softvera i +često su neophodne kako bi razvoj napredovao. Kad označavate deo javnog API-ja +kao deprecated (zastareli), potrebno je pratiti dve stvari: (1) ažurirati dokumentaciju +kako biste informisali korisnike, (2) objaviti novu minor (manju) verziju sa definisanim +deprecated (zastarelim) delovima softvera. Pre nego što potpuno uklonite funkcionalnost +u novoj major (glavnoj) verziji, potrebno je izdati barem jednu minor (manju) verziju koja +sadrži deprecated (zastarele) delove, kako bi korisnici nesmetano prešli na novu verziju API-ja. + +### Ima li SemVer ograničenje za veličinu stringa verzije? + +Ne, ali procenite sami. String verzije od 255 znakova je verovatno preteran, +na primer. Takođe, neki sistemi mogu imati svoja ograničenja +veličine stringa. + +### Da li je "v1.2.3" semantička verzija? + +Ne, "v1.2.3" nije semantička verzija. Međutim, dodavanje prefiksa "v" na semantičku +verziju je uobičajen način (na engleskom) da se naznači da je to broj verzije. +Skraćenje "version" na "v" se često vidi u kontroli verzija. Primer: +`git tag v1.2.3 -m "Release version 1.2.3"`, gde je "v1.2.3" naziv +tag-a (oznake), a semantička verzija je "1.2.3". + +### Da li postoji predloženi regularni izraz (RegEx) za proveru SemVer stringa? + +Postoje dva. Jedan sa imenovanim grupama za one sisteme koji ih podržavaju +(PCRE [Perl Compatible Regular Expressions (Perl kompatibilni regularni izrazi), tj. Perl, PHP i R], Python +i Go). + +Pogledajte: + +``` +^(?P0|[1-9]\d*)\.(?P0|[1-9]\d*)\.(?P0|[1-9]\d*)(?:-(?P(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ +``` + +I drugi sa numerisanim grupama (znači cg1 = major (glavna), cg2 = minor (manja), +cg3 = patch (zakrpa), cg4 = prerelease (predizdanje) i cg5 = buildmetadata (metapodaci)) koji su kompatibilni +sa ECMA Script (JavaScript), PCRE [Perl Compatible Regular Expressions (Perl kompatibilni regularni izrazi), +tj. Perl, PHP i R], Python i Go. + +Pogledajte: + +``` +^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ +``` + +O projektu +----- + +Autor specifikacije Semantičkog Verzionisanja je [Tom +Preston-Werner](https://tom.preston-werner.com), pronalazač Gravatar-a +i suosnivač GitHub-a. + +Ako želite ostaviti povratne informacije, molimo [otvorite issue na +GitHub-u](https://github.com/semver/semver/issues). + +Licenca +------- + +[Creative Commons ― CC BY 3.0](https://creativecommons.org/licenses/by/3.0/) diff --git a/lang/sr/index.md b/lang/sr/index.md deleted file mode 100644 index b666b698..00000000 --- a/lang/sr/index.md +++ /dev/null @@ -1,309 +0,0 @@ ---- -title: Semantičko Verzionisanje 2.0.0 -language: sr -author: Aleksandar Marinković ---- - -Semantičko Verzionisanje 2.0.0 -============================== - -Sažetak -------- - -Za dati broj verzije MAJOR.MINOR.PATCH, inkrementirajte: - -1. MAJOR (GLAVNU) verziju kada unesete nekompatibilne izmene API-ja -1. MINOR (MANJU) verziju kada dodate unazad kompatibilnu funkcionalnost -1. PATCH (ZAKRPU) verziju kada dodate unazad kompatibilne ispravke bug-ova (grešaka) - -Dodatne oznake za predizdanja i metapodatke build-a (izrade) dostupne su kao proširenja -u formatu MAJOR.MINOR.PATCH. - -Uvod ------------- - -U svetu upravljanja softverom postoji užasno mesto koje nazivamo -„pakao zavisnosti“. Kako vaš sistem raste i što više paketa -integrišete u svoj softver, veća je verovatnoća da ćete se naći -u ovom stanju dubokog očaja. - -U sistemima sa mnoštvom zavisnosti, objavljivanje novih verzija paketa može brzo -postati košmar. Ako su specifikacije zavisnosti suviše stroge, nalazite se u opasnosti -od zaključavanja verzije (nemogućnost nadogradnje paketa bez neophodne -objave nove verzije svakog zavisnog paketa). Takođe, ako su specifikacije zavisnosti isuviše labave, neizbežno će vas dovesti u situaciju verzijskog promiskuiteta -(pod pretpostavkom kompatibilnosti sa više budućih verzija nego što je razumno). -Pakao zavisnosti je situacija u kojoj se nalazite kada zaključavanje verzije i/ili verzijski promiskuitet sprečavaju jednostavno i bezbedno napredovanje projekta. - -Kao rešenje ovog problema, predlažemo jednostavan skup pravila i -zahteva koji diktiraju kako se brojevi verzija dodeljuju i inkrementiraju. -Ova pravila su zasnovana, ali nisu nužno ograničena na već postojeće i -široko rasprostranjene uobičajene prakse koje se koriste u closed i open-source -softveru. Kako bi ovaj sistem funkcionisao, neophodno je prvo objaviti public (javni) API. -Možemo to primeniti u dokumentaciji ili u samom kodu. U svakom slučaju, važno je da -API bude jasan i precizan. Jednom kad identifkujemo public API, izmene prenosimo -kroz specifikovane inkrementacije broja verzije. -Razmotrimo format verzije X.Y.Z (Major.Minor.Patch). Ispravke bug-ova (grešaka) koji -ne utiču na API inkrementiraju patch (zakrpa) verziju, a unazad nekompatibilne promene API-ju inkrementiraju major (glavnu) verziju. - -Ovaj sistem nazivamo „Semantičko Verzionisanje“. Prema ovoj šemi, brojevi verzija -i način na koji se menjaju daju informacije o osnovnom kodu koji se nalazi pod datom verzijom, kao i šta se menjalo od jedne verzije do sledeće. - -Specifikacija Semantičkog Verzionisanja (SemVer) ------------------------------------------------- - -Ključne reči "MUST" ("MORA"), "MUST NOT" ("NE SME"), "REQUIRED ("NEOPHODNO"), "SHALL"("HOĆE"), "SHALL NOT" ("NEĆE"),"SHOULD" ("TREBA"), "SHOULD NOT" ("NE TREBA"), "RECOMMENDED" ("PREPORUČENO"), "MAY" ("MOŽE") i "OPTIONAL" ("OPCIONO") u ovom dokumentu treba tumačiti kako je opisano u [RFC 2119](https://tools.ietf.org/html/rfc2119). - -1. Softver koji koristi Semantičko Verzionisanje MUST (MORA) objaviti publlic (javni) API. Ovaj API može biti deklarisan u samom kodu ili postojati striktno u dokumentaciji. -U svakom slučaju, SHOULD (TREBA) da bude precizan i sveobuhvatan. - -1. Normalna oznaka verzije MUST (MORA) biti u formatu X.Y.Z gde su X, Y i Z ne-negativni -celi brojevi i ne smeju počinjati sa nulom. X označava glavnu verziju, Y manju -verziju, a Z zakrpu. Svaki element MUST (MORA) se numerički inkrementirati. -Na primer: 1.9.0 -> 1.10.0 -> 1.11.0. - -1. Jednom kad je verzionisani paket objavljen, sadržaj te verzije MUST NOT (NE SME) se -menjati. Svaka izmena MUST (MORA) se objavljivati kao nova verzija. - -1. MAJOR (GLAVNA) verzija nula (0.y.z) je za inicijalni razvoj. Bilo šta se MAY (MOŽE) menjati -u svakom trenutku. Ovaj public (javni) API SHOULD NOT (NE TREBA) smatrati stabilnim. - -1. Verzija 1.0.0 definiše public (javni) API. Način na koji će se oznaka verzije -inkrementirati nakon ove objave zavisi od ovog public (javnog) API-ja i izmena na njemu. - -1. Patch (zakrpa) verzija Z (x.y.Z | x > 0) MUST (MORA) se inkrementirati kada se dodaju samo unazad kompatibilne ispravke bug-ova (gresaka). Ispravke bug-ova (gresaka) su definisane kao promene koda -koje ispravljaju nepravilno ponašanje. - -1. Minor (manja) verzija Y (x.Y.z | x > 0) MUST (MORA) se inkrementirati ako je nova, unazad kompatibilna funkcionalnost uvedena u javni API. Takođe MUST (MORA) se inkrementirati kada se neka od funkcionalnosti API-ja označi kao deprecated (zastarela). MAY (MOŽE) biti inkrementirana ukoliko se uvedu substancijalno nove funkcionalnosti ili poboljšanja u okviru privatnog koda. MAY (MOŽE) uključivati promene nivoa patch (zakrpe). Patch (Zakrpa) verzija MUST (MORA) se resetovati na 0 kada se minor (manja) verzija inkrementira. - -1. Major (glavna) verzija X (X.y.z | X > 0) MUST (MORA) se inkrementirati ako se unazad nekompatibilne promene uvode u javni API. MAY (MOŽE) uključivati i promene minor (manje) i promene na nivou patch -(zakrpe) verzije. Patch (zakrpe) i minor (manje) verzije MUST (MORA) da se resetuju na 0 kada se -major (glavna) verzija inkrementira. - -1. Verzija predizdanja MAY (MOŽE) biti označena dodavanjem hyphen-a (povlake) i serijom identifikatora razdvojenih tačkom neposredno nakon patch (zakrpe) verzije. Identifikatori MUST (MORAJU) sadržati samo ASCII alfanumeričke znakove i hyphen-e (povlake) -[0-9A-Za-z-]. Identifikatori MUST NOT (NE SMEJU) biti prazni. Numerički identifikatori MUST NOT (NE SMEJU) počinjati nulom. Verzije predizdanja imaju niži prioritet od povezane normalne verzije. Verzija predizdanja označava da je verzija nestabilna i da možda neće biti zadovoljeni predviđeni zahtevi kompatibilnosti kao što je označeno njenom povezanom normalnom verzijom. Primeri: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, -1.0.0-x.7.z.92, 1.0.0-x-y-z.\-\-. - -1. Metadata (metapodaci) build-a (izrade) MAY (MOGU) biti označeni dodavanjem znaka plus -i niza identifikatora odvojenih tačkom, koji se odmah nastavljaju na patch (zakrpu) verziju ili verziju predizdanja. Identifikatori MUST (MORAJU) da sadrže iskljucivo ASCII alfanumeričke znakove i hyphen-e (povlake) [0-9A-Za-z-]. Identifikatori MUST NOT (NE SMEJU) da budu prazni. Metadata (metapodaci) o build-u (izgradnji) MUST (MORAJU) se zanemariti prilikom određivanja prioriteta verzije. Prema tome dve verzije koje se razlikuju samo u metapodacima build-a (izrade), imaju isti prioritet. Primeri: -1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, -1.0.0+21AF26D3\-\-\-\-117B344092BD. - -1. Prioritet se odnosi na način kojim se verzije u poretku međusobno upoređuju. - - 1. Prioritet se MUST (MORA) izračunati razdvajanjem verzije na major (glavne), - minor (manje), patch (zakrpe) i identifikatore predizdanja (metadata (metapodaci) build-a (izrade) nemaju ulogu u određivanju prioriteta). - - 1. Prioritet se određuje prvom razlikom kada se upoređuje svaki od identifikatora sa leva na desno: - major (glavni), minor (manji) i patch (zakrpa). Verzije se uvek upoređuju brojčano. - - Primer: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. - - 1. Kada su major (glavna), minor (manja) i patch (zakrpa) jednake, verzija predizdanja ima niži - prioritet od normalne verzije. - - Primer: 1.0.0-alpha < 1.0.0. - - 1. Prioritet između dve verzije predizdanja sa jednakim major (glavnom), minor (manjom) i patch - (zakrpom) MUST (MORA) biti određen upoređivanjem svakog identifikatora razdvojenog tačkama sa leva na desno dok se ne pronađe razlika na sledeći način: - - 1. Identifikatori koji se sastoje samo od cifara upoređuju se numerički. - - 1. Identifikatori sa slovima ili hyphen-ima (povlakama) se upoređuju leksički u ASCII - poretku. - - 1. Numerički identifikatori uvek imaju niži prioritet od nenumeričkih - identifikatora. - - 1. Veći skup oznaka predizdanja ima viši prioritet od manjeg skupa, ako su svi prethodni - identifikatori jednaki. - - Primer: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < - 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. - -Backus–Naur Gramatički Obrazac za Validne SemVer Verzije --------------------------------------------------------- - -``` - ::= - | "-" - | "+" - | "-" "+" - - ::= "." "." - - ::= - - ::= - - ::= - - ::= - - ::= - | "." - - ::= - - ::= - | "." - - ::= - | - - ::= - | - - ::= - | - | - | - - ::= "0" - | - | - - ::= - | - - ::= - | - - ::= - | "-" - - ::= - | - - ::= "0" - | - - ::= "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" - - ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" - | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" - | "U" | "V" | "W" | "X" | "Y" | "Z" | "a" | "b" | "c" | "d" - | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" - | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" - | "y" | "z" -``` - -Zašto koristiti Semantičko Verzionisanje? ------------------------------------------ - -Ovo nije nova ili revolucionarna ideja. Tačnije, verovatno već radite nešto vrlo slično. Problem je što nešto "slično" nije dovoljno dobro. Bez usaglašenosti sa nekom vrstom formalne specifikacije, brojevi verzija su -u suštini beskorisni za upravljanje zavisnostima. Davanjem imena i jasne -definicije gore navedenih ideja, postaje lako preneti svoje namere -korisnicima vašeg softvera. Jednom kada su ove namere jasne, fleksibilne (ali -ne previše fleksibilne) specifikacije zavisnosti konačno je moguće napraviti. - -Jednostavan primer može pokazati kako pakao zavisnosti uz Semantičko Verzionisanje ostaje stvar prošlosti. Zamislite library (biblioteku) pod nazivom "Vatrogasno_vozilo". Neophodan joj je Semantičko Verzionisani paket pod nazivom "Merdevine". U trenutku kreiranja Vatrogasno_vozilo, Merdevine su u verziji 3.1.0. Pošto Vatrogasno_vozilo koristi neke funkcije prvobitno uvedene -u 3.1.0, možete bezbedno specifikovati zavisnost od Merdevine kao veću ili jednaku 3.1.0, ali manju od 4.0.0. Sada, kada Merdevine verzije 3.1.1 i 3.2.0 postanu dostupne, možete ih uneti u svoj sistem upravljanja paketima i biti siguni da će biti kompatibilni sa postojećim zavisnim softverom. - -Kao odgovoran programer, vi ćete, naravno, želeti da verifikujete da li upgrade (nadgradnje) paketa funkcionišu kako je navedeno. Stvarni svet je mahom neuređeno mesto; ne možemo ništa uraditi povodom toga osim da budemo oprezni. -Ono što možemo uciniti je da usvojimo Semantičko Verzionisanje koje nam pruža razuman način za objavljivanje i nadogradnju paketa, bez potrebe za pokretanjem novih verzija zavisnih paketa, štedeći vreme i trud. - -Ako vam ovo zvuči poželjno, sve što je potrebno uraditi da biste počeli da koristite Semantičko Verzionisanje je da se deklarišete kao korisnik i da potom -sledite pravila. Linkujte ovaj website sa vašim README-ma tako da bi i drugi bili svesni pravila i mogu imati koristi od njih. - -FAQ ---- - -### Kako se nositi sa revizijama 0.y.z u inicijalnoj fazi razvoja? - -Najjednostavniji način je da započnete inicijalni razvoj objavom verzije -0.1.0 i potom inkrementirate oznaku minor (manje) verzije za svako sledeće izdanje. - -### Kako da znamo kada treba objaviti verziju 1.0.0?? - -Ako se softver koristi u produkciji, već bi verovatno trebalo biti 1.0.0. Ako već imate stabilni API, na koji se korisnici mogu pouzdati, trebalo bi -biti 1.0.0. Ukoliko ste prilično zabrinuti oko kompatibilnosti unazad, softver -bi već trebalo da je objavljen pod verzijom 1.0.0. - -### Zar to ne obeshrabruje rapidan razvoj i brzu iteraciju? - -Major (glavna) verzija nula je zapravo predodređena rapidnom razvoju. Ako menjate API svaki dan, trebalo bi ostati na verziji 0.y.z ili na posebnoj grani za razvoj raditi na sledećoj major (glavnoj) verziji. - -### Ukoliko i najsitnije unazad nekompatibilne izmene u API-ju zahtevaju naglo uvećavanje major (glavne) verzije, nećemo li vrlo brzo doći do verzije 42.0.0? - -Ovo je pitanje odgovornog razvoja i predviđanja. U softver koji ima puno -zavisnog koda, nekompatibilne promene ne treba olako uvoditi. Troškovi -nadogradnje mogu biti značajni. Ako morate povećati major (glavnu) verziju, kako biste objavili verziju sa nekompatibilnim izmenama, morate razmisliti o uticaju tih izmena i proceniti odnos uključenih troškova i koristi. - -### Dokumentacija celokupnog public (javnog) API-ja zahteva previše posla - -Vaša je odgovornost kao profesionalnih programera da pravilno dokumentujete -softver koji je namenjen korisnicima. Upravljanje složenošću softvera je izuzetno važan deo održavanja efikasnosti projekta, što je teško ako korisnici ne znaju kako koristiti vaš softver ili koje metode mogu bezbedno pozvati. Dugoročno, Semantičko Verzionisanje i insistiranje na kvalitetno definisanom API-ju omogućiće da svi i sve rade glatko. - -### Šta ukoliko slučajno objavimo unazad nekompatibilne izmene kao minor (manju) verziju? - -Čim primetite da ste prekršili specifikacije Semantičkog Verzionisanja, -potrebno je ispraviti grešku pa objaviti minor (manju) verziju koja će ispraviti problem i povratiti kompatibilnost unazad. Čak i u takvim uslovima, nije prihvatljivo modifikovati verzionisane objave. Ako je prikladno, dokumentujte verziju koja krši specifikaciju i tako obavestite korisnike kako bi bili svesni toga. - -### Šta činiti ukoliko izmenimo sopstvene zavisnosti bez promene public (javnog) API-ja? - -Takve izmene smatramo kompatibilnima jer ne utiču na public (javni) API. Softver koji -eksplicitno zavisi od istih zavisnosti kao i naš sopstveni paket treba imati vlastite specifikacije zavisnosti, a autor će primetiti eventualne konflikte. Je li promjena na nivou patch (zakrpe) ili minor (manje) verzije, zavisi od toga da li ste dodavali svoje zavisnosti kao ispravke bug-ova (grešaka) ili ste ih uveli kao nove funkcionalnosti. U posljednjem slučaju -možemo očekivati i dodatni kod, pri čemu se očigledno radi o inkrementu minor (manje) verzije. - -### Šta ukoliko slučajno izmenimo public (javni) API na način koji ne odgovara izmeni broja verzije (npr. u kod neispravno uvedemo veću unazad nekompatibilnu izmenu u okviru objave patch (zakrpe))? - -Koristite svoju najbolju procenu. Ako imate veliki broj korisnika, na koje će -značajno uticati promena unatrag, najbolje je da objavite major (glavnu) verziju, iako -bi takav ispravak mogli smatrati izdanjem zakrpe. Zapamtite, svrha Semantičkog -Verzionisanja je prenošenje značenja putem izmene broja verzije. Ako su takve -izmene važne za vaše korisnike, koristite broj verzije da biste ih informisali. - -### Kako postupati sa deprecating (zastarelim) funkcionalnostima? - -Postojeće funkcionalnosti koje zastarevaju, sastavni su deo razvoja softvera -i često su neophodne kako bi razvoj napredovao. Kad označavate deo public (javnog) API-ja kao deprecated (zastareli), potrebno je učiniti dve stvari: (1) ažurirati dokumentaciju kako bismo informisali korisnike, (2) objaviti novu minor (manju) verziju sa definisanim deprecated (zastarelim) delovima softvera. Pre nego što potpuno uklonite funkcionalnost u novoj major (glavnoj) verziji, potrebno je izdati barem jednu minor (manju) verziju koja sadrži deprecated (zastarele) delove, kako bi korisnici nesmetano prešli na novu verziju API-ja. - -### Ima li SemVer ograničenu veličinu stringa verzije? - -Ne, ali procenite sami. String verzije od 255 znakova je verovatno preteran, -na primer. Takođe, neki sistemi mogu imati svoja ograničenja veličine stringa. - -### Da li je "v1.2.3" semantička verzija? - -Ne, "v1.2.3" nije semantička verzija. Međutim, prefiksiranje semantičke verzije -sa "v" je uobičajen način (na engleskom) da se naznači da je to broj verzije. -Skraćenje "verzije" kao "v" se često vidi sa kontrolom verzija. Primer: -`git tag v1.2.3 -m "Release version 1.2.3"`, u kom slučaju je "v1.2.3" naziv -taga (oznake), a semantička verzija je "1.2.3". - -### Da li postoji predloženi regularni izraz (RegEx) za proveru SemVer stringa? - -Postoje dva. Jedan sa imenovanim grupama za one sisteme koji ih podržavaju -(PCRE [Perl Compatible Regular Expressions (Perl kompatibilni regularni izrazi), tj. Perl, PHP i R], Python -i Go). - -Pogledajte: - -``` -^(?P0|[1-9]\d*)\.(?P0|[1-9]\d*)\.(?P0|[1-9]\d*)(?:-(?P(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ -``` - -I drugi sa numerisanim grupama (znači ng1 = major (glavna), ng2 = minor (manja), -ng3 = patch (zakrpa), ng4 = prerelease (predizdanje) i ng5 = buildmetadata (metapodaci)) koji su kompatibilni -sa ECMA Script (JavaScript), PCRE [Perl Compatible Regular Expressions (Perl kompatibilni regularni izrazi), -tj. Perl, PHP i R], Python i Go. - -Pogledajte: - -``` -^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ -``` - -O projektu ----------- - -Autor specifikacije Semantičkog Verzionisanja je [Tom -Preston-Werner](http://tom.preston-werner.com), pronalazač Gravatar-a i suosnivač GitHub-a. - -Ako želite ostaviti povratne informacije, molimo [otvorite issue na -GitHub-u](https://github.com/semver/semver/issues). - -Licenca -------- - -[Creative Commons ― CC BY 3.0](https://creativecommons.org/licenses/by/3.0/) diff --git a/lang/sr/spec/v2.0.0.md b/lang/sr/spec/v2.0.0.md deleted file mode 100644 index b666b698..00000000 --- a/lang/sr/spec/v2.0.0.md +++ /dev/null @@ -1,309 +0,0 @@ ---- -title: Semantičko Verzionisanje 2.0.0 -language: sr -author: Aleksandar Marinković ---- - -Semantičko Verzionisanje 2.0.0 -============================== - -Sažetak -------- - -Za dati broj verzije MAJOR.MINOR.PATCH, inkrementirajte: - -1. MAJOR (GLAVNU) verziju kada unesete nekompatibilne izmene API-ja -1. MINOR (MANJU) verziju kada dodate unazad kompatibilnu funkcionalnost -1. PATCH (ZAKRPU) verziju kada dodate unazad kompatibilne ispravke bug-ova (grešaka) - -Dodatne oznake za predizdanja i metapodatke build-a (izrade) dostupne su kao proširenja -u formatu MAJOR.MINOR.PATCH. - -Uvod ------------- - -U svetu upravljanja softverom postoji užasno mesto koje nazivamo -„pakao zavisnosti“. Kako vaš sistem raste i što više paketa -integrišete u svoj softver, veća je verovatnoća da ćete se naći -u ovom stanju dubokog očaja. - -U sistemima sa mnoštvom zavisnosti, objavljivanje novih verzija paketa može brzo -postati košmar. Ako su specifikacije zavisnosti suviše stroge, nalazite se u opasnosti -od zaključavanja verzije (nemogućnost nadogradnje paketa bez neophodne -objave nove verzije svakog zavisnog paketa). Takođe, ako su specifikacije zavisnosti isuviše labave, neizbežno će vas dovesti u situaciju verzijskog promiskuiteta -(pod pretpostavkom kompatibilnosti sa više budućih verzija nego što je razumno). -Pakao zavisnosti je situacija u kojoj se nalazite kada zaključavanje verzije i/ili verzijski promiskuitet sprečavaju jednostavno i bezbedno napredovanje projekta. - -Kao rešenje ovog problema, predlažemo jednostavan skup pravila i -zahteva koji diktiraju kako se brojevi verzija dodeljuju i inkrementiraju. -Ova pravila su zasnovana, ali nisu nužno ograničena na već postojeće i -široko rasprostranjene uobičajene prakse koje se koriste u closed i open-source -softveru. Kako bi ovaj sistem funkcionisao, neophodno je prvo objaviti public (javni) API. -Možemo to primeniti u dokumentaciji ili u samom kodu. U svakom slučaju, važno je da -API bude jasan i precizan. Jednom kad identifkujemo public API, izmene prenosimo -kroz specifikovane inkrementacije broja verzije. -Razmotrimo format verzije X.Y.Z (Major.Minor.Patch). Ispravke bug-ova (grešaka) koji -ne utiču na API inkrementiraju patch (zakrpa) verziju, a unazad nekompatibilne promene API-ju inkrementiraju major (glavnu) verziju. - -Ovaj sistem nazivamo „Semantičko Verzionisanje“. Prema ovoj šemi, brojevi verzija -i način na koji se menjaju daju informacije o osnovnom kodu koji se nalazi pod datom verzijom, kao i šta se menjalo od jedne verzije do sledeće. - -Specifikacija Semantičkog Verzionisanja (SemVer) ------------------------------------------------- - -Ključne reči "MUST" ("MORA"), "MUST NOT" ("NE SME"), "REQUIRED ("NEOPHODNO"), "SHALL"("HOĆE"), "SHALL NOT" ("NEĆE"),"SHOULD" ("TREBA"), "SHOULD NOT" ("NE TREBA"), "RECOMMENDED" ("PREPORUČENO"), "MAY" ("MOŽE") i "OPTIONAL" ("OPCIONO") u ovom dokumentu treba tumačiti kako je opisano u [RFC 2119](https://tools.ietf.org/html/rfc2119). - -1. Softver koji koristi Semantičko Verzionisanje MUST (MORA) objaviti publlic (javni) API. Ovaj API može biti deklarisan u samom kodu ili postojati striktno u dokumentaciji. -U svakom slučaju, SHOULD (TREBA) da bude precizan i sveobuhvatan. - -1. Normalna oznaka verzije MUST (MORA) biti u formatu X.Y.Z gde su X, Y i Z ne-negativni -celi brojevi i ne smeju počinjati sa nulom. X označava glavnu verziju, Y manju -verziju, a Z zakrpu. Svaki element MUST (MORA) se numerički inkrementirati. -Na primer: 1.9.0 -> 1.10.0 -> 1.11.0. - -1. Jednom kad je verzionisani paket objavljen, sadržaj te verzije MUST NOT (NE SME) se -menjati. Svaka izmena MUST (MORA) se objavljivati kao nova verzija. - -1. MAJOR (GLAVNA) verzija nula (0.y.z) je za inicijalni razvoj. Bilo šta se MAY (MOŽE) menjati -u svakom trenutku. Ovaj public (javni) API SHOULD NOT (NE TREBA) smatrati stabilnim. - -1. Verzija 1.0.0 definiše public (javni) API. Način na koji će se oznaka verzije -inkrementirati nakon ove objave zavisi od ovog public (javnog) API-ja i izmena na njemu. - -1. Patch (zakrpa) verzija Z (x.y.Z | x > 0) MUST (MORA) se inkrementirati kada se dodaju samo unazad kompatibilne ispravke bug-ova (gresaka). Ispravke bug-ova (gresaka) su definisane kao promene koda -koje ispravljaju nepravilno ponašanje. - -1. Minor (manja) verzija Y (x.Y.z | x > 0) MUST (MORA) se inkrementirati ako je nova, unazad kompatibilna funkcionalnost uvedena u javni API. Takođe MUST (MORA) se inkrementirati kada se neka od funkcionalnosti API-ja označi kao deprecated (zastarela). MAY (MOŽE) biti inkrementirana ukoliko se uvedu substancijalno nove funkcionalnosti ili poboljšanja u okviru privatnog koda. MAY (MOŽE) uključivati promene nivoa patch (zakrpe). Patch (Zakrpa) verzija MUST (MORA) se resetovati na 0 kada se minor (manja) verzija inkrementira. - -1. Major (glavna) verzija X (X.y.z | X > 0) MUST (MORA) se inkrementirati ako se unazad nekompatibilne promene uvode u javni API. MAY (MOŽE) uključivati i promene minor (manje) i promene na nivou patch -(zakrpe) verzije. Patch (zakrpe) i minor (manje) verzije MUST (MORA) da se resetuju na 0 kada se -major (glavna) verzija inkrementira. - -1. Verzija predizdanja MAY (MOŽE) biti označena dodavanjem hyphen-a (povlake) i serijom identifikatora razdvojenih tačkom neposredno nakon patch (zakrpe) verzije. Identifikatori MUST (MORAJU) sadržati samo ASCII alfanumeričke znakove i hyphen-e (povlake) -[0-9A-Za-z-]. Identifikatori MUST NOT (NE SMEJU) biti prazni. Numerički identifikatori MUST NOT (NE SMEJU) počinjati nulom. Verzije predizdanja imaju niži prioritet od povezane normalne verzije. Verzija predizdanja označava da je verzija nestabilna i da možda neće biti zadovoljeni predviđeni zahtevi kompatibilnosti kao što je označeno njenom povezanom normalnom verzijom. Primeri: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, -1.0.0-x.7.z.92, 1.0.0-x-y-z.\-\-. - -1. Metadata (metapodaci) build-a (izrade) MAY (MOGU) biti označeni dodavanjem znaka plus -i niza identifikatora odvojenih tačkom, koji se odmah nastavljaju na patch (zakrpu) verziju ili verziju predizdanja. Identifikatori MUST (MORAJU) da sadrže iskljucivo ASCII alfanumeričke znakove i hyphen-e (povlake) [0-9A-Za-z-]. Identifikatori MUST NOT (NE SMEJU) da budu prazni. Metadata (metapodaci) o build-u (izgradnji) MUST (MORAJU) se zanemariti prilikom određivanja prioriteta verzije. Prema tome dve verzije koje se razlikuju samo u metapodacima build-a (izrade), imaju isti prioritet. Primeri: -1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, -1.0.0+21AF26D3\-\-\-\-117B344092BD. - -1. Prioritet se odnosi na način kojim se verzije u poretku međusobno upoređuju. - - 1. Prioritet se MUST (MORA) izračunati razdvajanjem verzije na major (glavne), - minor (manje), patch (zakrpe) i identifikatore predizdanja (metadata (metapodaci) build-a (izrade) nemaju ulogu u određivanju prioriteta). - - 1. Prioritet se određuje prvom razlikom kada se upoređuje svaki od identifikatora sa leva na desno: - major (glavni), minor (manji) i patch (zakrpa). Verzije se uvek upoređuju brojčano. - - Primer: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. - - 1. Kada su major (glavna), minor (manja) i patch (zakrpa) jednake, verzija predizdanja ima niži - prioritet od normalne verzije. - - Primer: 1.0.0-alpha < 1.0.0. - - 1. Prioritet između dve verzije predizdanja sa jednakim major (glavnom), minor (manjom) i patch - (zakrpom) MUST (MORA) biti određen upoređivanjem svakog identifikatora razdvojenog tačkama sa leva na desno dok se ne pronađe razlika na sledeći način: - - 1. Identifikatori koji se sastoje samo od cifara upoređuju se numerički. - - 1. Identifikatori sa slovima ili hyphen-ima (povlakama) se upoređuju leksički u ASCII - poretku. - - 1. Numerički identifikatori uvek imaju niži prioritet od nenumeričkih - identifikatora. - - 1. Veći skup oznaka predizdanja ima viši prioritet od manjeg skupa, ako su svi prethodni - identifikatori jednaki. - - Primer: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < - 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. - -Backus–Naur Gramatički Obrazac za Validne SemVer Verzije --------------------------------------------------------- - -``` - ::= - | "-" - | "+" - | "-" "+" - - ::= "." "." - - ::= - - ::= - - ::= - - ::= - - ::= - | "." - - ::= - - ::= - | "." - - ::= - | - - ::= - | - - ::= - | - | - | - - ::= "0" - | - | - - ::= - | - - ::= - | - - ::= - | "-" - - ::= - | - - ::= "0" - | - - ::= "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" - - ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" - | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" - | "U" | "V" | "W" | "X" | "Y" | "Z" | "a" | "b" | "c" | "d" - | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" - | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" - | "y" | "z" -``` - -Zašto koristiti Semantičko Verzionisanje? ------------------------------------------ - -Ovo nije nova ili revolucionarna ideja. Tačnije, verovatno već radite nešto vrlo slično. Problem je što nešto "slično" nije dovoljno dobro. Bez usaglašenosti sa nekom vrstom formalne specifikacije, brojevi verzija su -u suštini beskorisni za upravljanje zavisnostima. Davanjem imena i jasne -definicije gore navedenih ideja, postaje lako preneti svoje namere -korisnicima vašeg softvera. Jednom kada su ove namere jasne, fleksibilne (ali -ne previše fleksibilne) specifikacije zavisnosti konačno je moguće napraviti. - -Jednostavan primer može pokazati kako pakao zavisnosti uz Semantičko Verzionisanje ostaje stvar prošlosti. Zamislite library (biblioteku) pod nazivom "Vatrogasno_vozilo". Neophodan joj je Semantičko Verzionisani paket pod nazivom "Merdevine". U trenutku kreiranja Vatrogasno_vozilo, Merdevine su u verziji 3.1.0. Pošto Vatrogasno_vozilo koristi neke funkcije prvobitno uvedene -u 3.1.0, možete bezbedno specifikovati zavisnost od Merdevine kao veću ili jednaku 3.1.0, ali manju od 4.0.0. Sada, kada Merdevine verzije 3.1.1 i 3.2.0 postanu dostupne, možete ih uneti u svoj sistem upravljanja paketima i biti siguni da će biti kompatibilni sa postojećim zavisnim softverom. - -Kao odgovoran programer, vi ćete, naravno, želeti da verifikujete da li upgrade (nadgradnje) paketa funkcionišu kako je navedeno. Stvarni svet je mahom neuređeno mesto; ne možemo ništa uraditi povodom toga osim da budemo oprezni. -Ono što možemo uciniti je da usvojimo Semantičko Verzionisanje koje nam pruža razuman način za objavljivanje i nadogradnju paketa, bez potrebe za pokretanjem novih verzija zavisnih paketa, štedeći vreme i trud. - -Ako vam ovo zvuči poželjno, sve što je potrebno uraditi da biste počeli da koristite Semantičko Verzionisanje je da se deklarišete kao korisnik i da potom -sledite pravila. Linkujte ovaj website sa vašim README-ma tako da bi i drugi bili svesni pravila i mogu imati koristi od njih. - -FAQ ---- - -### Kako se nositi sa revizijama 0.y.z u inicijalnoj fazi razvoja? - -Najjednostavniji način je da započnete inicijalni razvoj objavom verzije -0.1.0 i potom inkrementirate oznaku minor (manje) verzije za svako sledeće izdanje. - -### Kako da znamo kada treba objaviti verziju 1.0.0?? - -Ako se softver koristi u produkciji, već bi verovatno trebalo biti 1.0.0. Ako već imate stabilni API, na koji se korisnici mogu pouzdati, trebalo bi -biti 1.0.0. Ukoliko ste prilično zabrinuti oko kompatibilnosti unazad, softver -bi već trebalo da je objavljen pod verzijom 1.0.0. - -### Zar to ne obeshrabruje rapidan razvoj i brzu iteraciju? - -Major (glavna) verzija nula je zapravo predodređena rapidnom razvoju. Ako menjate API svaki dan, trebalo bi ostati na verziji 0.y.z ili na posebnoj grani za razvoj raditi na sledećoj major (glavnoj) verziji. - -### Ukoliko i najsitnije unazad nekompatibilne izmene u API-ju zahtevaju naglo uvećavanje major (glavne) verzije, nećemo li vrlo brzo doći do verzije 42.0.0? - -Ovo je pitanje odgovornog razvoja i predviđanja. U softver koji ima puno -zavisnog koda, nekompatibilne promene ne treba olako uvoditi. Troškovi -nadogradnje mogu biti značajni. Ako morate povećati major (glavnu) verziju, kako biste objavili verziju sa nekompatibilnim izmenama, morate razmisliti o uticaju tih izmena i proceniti odnos uključenih troškova i koristi. - -### Dokumentacija celokupnog public (javnog) API-ja zahteva previše posla - -Vaša je odgovornost kao profesionalnih programera da pravilno dokumentujete -softver koji je namenjen korisnicima. Upravljanje složenošću softvera je izuzetno važan deo održavanja efikasnosti projekta, što je teško ako korisnici ne znaju kako koristiti vaš softver ili koje metode mogu bezbedno pozvati. Dugoročno, Semantičko Verzionisanje i insistiranje na kvalitetno definisanom API-ju omogućiće da svi i sve rade glatko. - -### Šta ukoliko slučajno objavimo unazad nekompatibilne izmene kao minor (manju) verziju? - -Čim primetite da ste prekršili specifikacije Semantičkog Verzionisanja, -potrebno je ispraviti grešku pa objaviti minor (manju) verziju koja će ispraviti problem i povratiti kompatibilnost unazad. Čak i u takvim uslovima, nije prihvatljivo modifikovati verzionisane objave. Ako je prikladno, dokumentujte verziju koja krši specifikaciju i tako obavestite korisnike kako bi bili svesni toga. - -### Šta činiti ukoliko izmenimo sopstvene zavisnosti bez promene public (javnog) API-ja? - -Takve izmene smatramo kompatibilnima jer ne utiču na public (javni) API. Softver koji -eksplicitno zavisi od istih zavisnosti kao i naš sopstveni paket treba imati vlastite specifikacije zavisnosti, a autor će primetiti eventualne konflikte. Je li promjena na nivou patch (zakrpe) ili minor (manje) verzije, zavisi od toga da li ste dodavali svoje zavisnosti kao ispravke bug-ova (grešaka) ili ste ih uveli kao nove funkcionalnosti. U posljednjem slučaju -možemo očekivati i dodatni kod, pri čemu se očigledno radi o inkrementu minor (manje) verzije. - -### Šta ukoliko slučajno izmenimo public (javni) API na način koji ne odgovara izmeni broja verzije (npr. u kod neispravno uvedemo veću unazad nekompatibilnu izmenu u okviru objave patch (zakrpe))? - -Koristite svoju najbolju procenu. Ako imate veliki broj korisnika, na koje će -značajno uticati promena unatrag, najbolje je da objavite major (glavnu) verziju, iako -bi takav ispravak mogli smatrati izdanjem zakrpe. Zapamtite, svrha Semantičkog -Verzionisanja je prenošenje značenja putem izmene broja verzije. Ako su takve -izmene važne za vaše korisnike, koristite broj verzije da biste ih informisali. - -### Kako postupati sa deprecating (zastarelim) funkcionalnostima? - -Postojeće funkcionalnosti koje zastarevaju, sastavni su deo razvoja softvera -i često su neophodne kako bi razvoj napredovao. Kad označavate deo public (javnog) API-ja kao deprecated (zastareli), potrebno je učiniti dve stvari: (1) ažurirati dokumentaciju kako bismo informisali korisnike, (2) objaviti novu minor (manju) verziju sa definisanim deprecated (zastarelim) delovima softvera. Pre nego što potpuno uklonite funkcionalnost u novoj major (glavnoj) verziji, potrebno je izdati barem jednu minor (manju) verziju koja sadrži deprecated (zastarele) delove, kako bi korisnici nesmetano prešli na novu verziju API-ja. - -### Ima li SemVer ograničenu veličinu stringa verzije? - -Ne, ali procenite sami. String verzije od 255 znakova je verovatno preteran, -na primer. Takođe, neki sistemi mogu imati svoja ograničenja veličine stringa. - -### Da li je "v1.2.3" semantička verzija? - -Ne, "v1.2.3" nije semantička verzija. Međutim, prefiksiranje semantičke verzije -sa "v" je uobičajen način (na engleskom) da se naznači da je to broj verzije. -Skraćenje "verzije" kao "v" se često vidi sa kontrolom verzija. Primer: -`git tag v1.2.3 -m "Release version 1.2.3"`, u kom slučaju je "v1.2.3" naziv -taga (oznake), a semantička verzija je "1.2.3". - -### Da li postoji predloženi regularni izraz (RegEx) za proveru SemVer stringa? - -Postoje dva. Jedan sa imenovanim grupama za one sisteme koji ih podržavaju -(PCRE [Perl Compatible Regular Expressions (Perl kompatibilni regularni izrazi), tj. Perl, PHP i R], Python -i Go). - -Pogledajte: - -``` -^(?P0|[1-9]\d*)\.(?P0|[1-9]\d*)\.(?P0|[1-9]\d*)(?:-(?P(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ -``` - -I drugi sa numerisanim grupama (znači ng1 = major (glavna), ng2 = minor (manja), -ng3 = patch (zakrpa), ng4 = prerelease (predizdanje) i ng5 = buildmetadata (metapodaci)) koji su kompatibilni -sa ECMA Script (JavaScript), PCRE [Perl Compatible Regular Expressions (Perl kompatibilni regularni izrazi), -tj. Perl, PHP i R], Python i Go. - -Pogledajte: - -``` -^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ -``` - -O projektu ----------- - -Autor specifikacije Semantičkog Verzionisanja je [Tom -Preston-Werner](http://tom.preston-werner.com), pronalazač Gravatar-a i suosnivač GitHub-a. - -Ako želite ostaviti povratne informacije, molimo [otvorite issue na -GitHub-u](https://github.com/semver/semver/issues). - -Licenca -------- - -[Creative Commons ― CC BY 3.0](https://creativecommons.org/licenses/by/3.0/) From 6e55fc7391ec4b4cb8b5de6f4b05baede86ae208 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rado=C5=A1=20Mili=C4=87ev?= <40705899+rammba@users.noreply.github.com> Date: Sun, 31 Aug 2025 16:18:27 +0200 Subject: [PATCH 3/4] Update _config.yml --- _config.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/_config.yml b/_config.yml index 6b8c2ea9..041c8b3e 100644 --- a/_config.yml +++ b/_config.yml @@ -14,7 +14,8 @@ languages: ko: 한국어 sk: slovensky sl: slovenščina - sr: srpski + sr-Cyrl: српски + sr-Latn: srpski ar: العربية ja: 日本語 ta: தமிழ் From 0196faa12a0ba880434f2ba4a238d7212e4f391e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rado=C5=A1=20Mili=C4=87ev?= <40705899+rammba@users.noreply.github.com> Date: Sun, 31 Aug 2025 16:20:51 +0200 Subject: [PATCH 4/4] Add lxmarinkovic to serbian translators --- TRANSLATORS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/TRANSLATORS.md b/TRANSLATORS.md index f1ac102d..2b731839 100644 --- a/TRANSLATORS.md +++ b/TRANSLATORS.md @@ -24,6 +24,7 @@ This file contains the translation contributors who are willing to help translat ## Serbian +- [@lxmarinkovic](https://github.com/lxmarinkovic) - [@rammba](https://github.com/rammba) ## Danish