Այս ֆորմատով ներկայացված տարբերակի համարի (version number) դեպքում՝ՄԱԺՈՐ․ՄԻՆՈՐ․ՓԱԹՉ (MAJOR.MINOR.PATCH), պետք է մեծացնել՝
Կարելի է անել նաև հավելյալ նշանակումներ՝ որպես հավելում ՄԱԺՈՐ․ՄԻՆՈՐ․ՓԱԹՉֆորմատին․ մինչթողարկումային (pre-release) պիտակ (label) և բիլդ-մետատվյալ(build metadata)։
Ծրագրային ապահովման մենեջմենթի աշխարհում գոյություն ունի «կախվածություններիդժոխք» (dependency hell) հասկացություն։ Ձեր համակարգի մեծացման և դրան ինտեգրվածփեքիջների քանակի ավելացման հետ մեծանում է հավանականությունը, որ դուք վաղ թե ուշ
կկանգնեք այս խնդրի առաջ։
Այն համակարգերում, որոնք ունեն շատ կախվածություններ, նոր տարբերակի թողարկումըկարող է արագ վերածվել մղձավանջի։ Եթե կախվածությունների սպեցիֆիկացիան շատ խիստ է,դուք կարող եք կանգնել նոր տարբերակի թողարկման արգելքի (version lock) առաջ(անհնար է դառնում թարմացնել ծրագիրը՝ առանց թարմացնելու կախման մեջ գտնվող բոլորփեքիջները)։ Մյուս կողմից էլ, եթե կախվածությունների սպեցիֆիկացիան շատ ազատ է,դուք անխուսափելիորեն կբախվեք տարբերակի անհամապատասխանության (versionpromiscuity) խնդրին․ անհիմն է ենթադրությունը, որ ձեր ծրագիրը կմնա համատեղելիապագա տարբերակների հետ։ «Կախվածությունների դժոխքը» մի իրավիճակ է, երբ տարբերակիթողարկման և/կամ տարբերակի անհապատասխանության արգելքը թույլ չի տալիս ձեզ հեշտ ևանվտանգ զարգացնել ձեր նախագիծը։
Որպես այս խնդրի լուծում՝ ես առաջարկում եմ պարզ կանոններ և պահանջներ, որոնքսահմանում են, թե ինչպես են սահմանվում և մեծացվում տարբերակների համարները։ Այսկանոնները հիմնված են (բայց ոչ անպայման սահմանափակված) բաց (open source) և փակ(closed source) ծրագրային ապահովման գոյություն ունեցող և լայն տարածում գտածպրակտիկաների վրա։ Նախևառաջ, որպեսզի այս կանոններն աշխատեն, դուք պետք է սահմանեքփաբլիք API: Այն կարող է նկարագրված լինել ինչպես դոկումենտացիայի, այնպես էլ կոդիմեջ։ Կարևոր է, որ API֊ը լինի ճիշտ և հասկանալի։ Ձեր API֊ը հայտարարելուց հետո դուքփոփոխությունների մասին կտեղեկացնեք տարբերակի համարը մեծացնելու միջոցով։Դիտարկենք այս ֆորմատով ներկայացված տարբերակ՝ X.Y.Z (ՄԱԺՈՐ․ՄԻՆՈՐ․ՓԱԹՉ)։ Սխալներիուղղումները (bug fix), որոենք չեն ազդել API-ի վրա, մեծացնում են ՓԱԹՉ֊ը։ Հետհամատեղելի հավելումները և փոփոխությունները մեծացնում են ՄԻՆՈՐ֊ը, հետհամատեղելիությունը խախտող փոփոխությունները մեծացնում են ՄԱԺՈՐ֊ը։
Ես անվանել եմ այս համակարգը «Սեմանտիկ տարբերակում» (Semantic Versioning): Այսսխեմայի միջոցով տարբերակի համարը և դրա փոխվելը իմաստավորում են կոդիպարունակությունը և նրանում եղած փոփոխությունները տարբերակից տարբերակ։
Նշված բառերը՝ «ՊԵՏՔ Է» (MUST, SHALL), «ՉՊԵՏՔ Է» (MUST NOT, SHALL NOT),«ՊԱՐՏԱԴԻՐ Է» (REQUIRED), «ԱՆՀՐԱԺԵՇՏ Է» (SHOULD), «ԱՆՀՐԱԺԵՇՏ ՉԷ» (SHOULD NOT),«ԽՈՐՀՈՒՐԴ Է ՏՐՎՈՒՄ» (RECOMMENDED), «ԿԱՐՈՂ Է» (MAY) և «ՊԱՐՏԱԴԻՐ ՉԷ» (OPTIONAL)պետք է ինտերպրիտացվենRFC 2119 ստանդարտինհամապատասխան։
Ծրագրային ապահովումը, որն օգտագործվում է Սեմանտիկ տարբերակում, ՊԵՏՔ Է (MUST)հայտարարի հասանելի փաբլիք API: Այդ API֊ը կարող է հայտարարվել ինչպես կոդի մեջ,այնպես էլ՝ առանձին դոկումենտացիայում։ Երկու դեպքում էլ այն պետք է լինի ճշգրիտ(precise) և սպառիչ (comprehensive)։
Տարբերակի ՆՈՐՄԱԼ համարը (normal version) ՊԵՏՔ Է (MUST) ունենա այս ֆորմատը՝X.Y.Z, որտեղ X, Y և Z թվերը ոչ բացասական ամբողջ թվեր են և ՉՊԵՏՔ է (MUST NOT)սկսվեն զրոյով։ X֊ը տարբերակի ՄԱԺՈՐ համարն է, Y֊ը՝ ՄԻՆՈՐ և Z֊ը՝ ՓԱԹՉ։ Բոլորբաղադիրչները պետք է մեծացվեն թվայնորեն․ օրինակ՝ 1.9.0 -> 1.10.0 -> 1.11.0։
Փեքիջի թողարկումից հետո այդ տարբերակի պարունակությունը ՉՊԵՏՔ է (MUST NOT)փոփոխության ենթարկվի։ Ցանկացած փոփոխություն ՊԵՏՔ Է (MUST) թողարկվի որպես նորտարբերակ։
Զրոյական ՄԱԺՈՐ տարբերակը (0.y.z) նախատեսված է ծրագրային ապահովմանստեղծման/մշակման նախնական փուլի (initial development) համար։ Ամեն ինչ կարող էփոխվել՝ կամայական պահի։ Փաբլիք API֊ը չպետք է դիտարկվի որպես ստաբիլ։
1.0.0 տարբերակի թողարկումից հետո API-ը համարվում է ստաբիլ, և տարբերակի համարըփոխվում է կախված նրանից, թե ինչպես է փոխվում փաբլիք API֊ը։
Տարբերակի ՓԱԹՉ համարը՝ Z (x.y.Z | x > 0), ՊԵՏՔ Է (MUST) մեծացվի, եթե տեղի ենունեցել միայն հետ համատեղելի սխալների ուղղումներ (bug fix)։ Սխալի ուղղում՝նշանակում է ներքին փոփոխություն, որը ուղղում է սխալ պահվածքը։
Տարբերակի ՄԻՆՈՐ համարը՝ Y (x.Y.z | x > 0), ՊԵՏՔ Է (MUST) մեծացվի, եթե փաբլիքAPI֊ում ավելացել է նոր հետ համատեղելի ֆունկցիոնալ։ Տարբերակի համարը ՊԵՏՔ Է(MUST) մեծացվի, եթե հասանելի փաբլիք API֊ի որևէ ֆունկցիոնալ պիտակավորվել էորպես հնացած (deprecated)։ Տարբերակի համարը ԿԱՐՈՂ Է (MAY) մեծացվել, եթե տեղիէ ունեցել նոր ֆունկցիոնալի ինտեգրացիա, կամ զգալի բարելավումներ են տեղիունեցել փրայվիթ կոդում։ Այն ԿԱՐՈՂ Է (MAY) նաև պարունակել ՓԱԹՉ մակարդակիփոփոխություններ։ Տարբերակի ՓԱԹՉ համարը ՊԵՏՔ Է (MUST) զրոյացվի, երբ մեծացվումէ ՄԻՆՈՐ համարը։
Տարբերակի ՄԱԺՈՐ համարը՝ X (X.y.z | X > 0), ՊԵՏՔ Է (MUST) մեծացվի, եթե փաբլիքAPI֊ում ներկայացվել են հետ համատեղելիությունը խախտող կամայականփոփոխություններ։ Այն ԿԱՐՈՂ Է (MAY) պարունակել նաև ՓԱԹՉ և ՄԻՆՈՐ մակարդակիփոփոխություններ։ Տարբերակի ՓԱԹՉ և ՄԻՆՈՐ համարները ՊԵՏՔ Է (MUST) զրոյացվեն,երբ մեծացվում է ՄԱԺՈՐ համարը։
Մինչթողարկումային (pre-release) տարբերակը ԿԱՐՈՂ Է (MAY) պիտակավորվելտարբերակի ՓԱԹՉ համարից անմիջապես հետո գծիկ և դրան հետևող կետիկով առանձնացվածտարբեր իդենտիֆիկատորներ ավելացնելու միջոցով։ Իդենտիֆիկատորները ՊԵՏՔ Է (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։
Բիլդ֊մետատվյալները (build-metadata) ԿԱՐՈՂ ԵՆ (MAY) պիտակավորվել տարբերակիՓԱԹՉ համարից կամ մինչթողարկումային տարբերակի իդենտիֆիկատորից անմիջապես հետոգումարման նշան և դրան հետևող կետիկով առանձնացված տարբեր իդենտիֆիկատորներավելացնելու միջոցով։ Իդենտիֆիկատորները ՊԵՏՔ Է (MUST) պարունակեն միայն ASCIIտառա֊թվային սիմվոլներ և գծիկ՝ [0-9A-Za-z-]։ Իդենտիֆիկատորները ՉՊԵՏՔ Է (MUSTNOT) լինեն դատարկ։ Բիլդ֊մետատվյալները ՊԵՏՔ Է (MUST) անտեսել տարբերակիԿԱՐԳԱՎԻՃԱԿԸ որոշելիս այսինքն, եթե նույն ծրագրի երկու տարբերակները տարբերվումեն միայն բիլդ֊մետատվյալներով, ուրեմն դրանք ունեն նույն ԿԱՐԳԱՎԻՃԱԿԸ․ օրինակ՝1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85։
ԿԱՐԳԱՎԻՃԱԿԸ (precedence) որոշում է, թե ինչպես է պետք համեմատել տարբերակներըմիմյանց հետ, երբ դրանք դասավորված են։ ԿԱՐԳԱՎԻՃԱԿԸ ՊԵՏՔ Է (MUST) հաշվելտարբերակի համարը՝ ՄԱԺՈՐ, ՄԻՆՈՐ, ՓԱԹՉ, և մինչթողարկումային իդենտիֆիկատորներըբաժանելու միջոցով։ ԿԱՐԳԱՎԻՃԱԿԸ որոշելիս բիլդ֊մետատվյալները հաշվի չեն առնվում։ԿԱՐԳԱՎԻՃԱԿԸ որոշվում է ՄԱԺՈՐ, ՄԻՆՈՐ, ՓԱԹՉ տարբերակի համարները ձախից աջթվայնորեն համեմատելու միջոցով․ օրինակ՝ 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1։ ԵրբՄԱԺՈՐ, ՄԻՆՈՐ և ՓԱԹՉ տարբերակի համարները հավասար են, մինչթողարկումայինտարբերակը ունենում է ավելի փոքր ԿԱՐԳԱՎԻՃԱԿ, քան ՆՈՐՄԱԼ տարբերակը․ օրինակ՝1.0.0-alpha < 1.0.0։ Երբ տարբերակների ՄԱԺՈՐ, ՄԻՆՈՐ և ՓԱԹՉ համարները հավասարեն, ԿԱՐԳԱՎԻՃԱԿԸ ՊԵՏՔ Է (MUST) որոշել մինչթողարկումային տարբերակի միջոցով՝ձախից աջ կետով առանձնացված իդենտիֆիկատորները համեմատելով մինչև առաջինտարբերող իդենտիֆիկատոր գտնելը։ Մինչթողարկումային տարբերակները համեմատվում ենտվյալ եղանակով՝ իդենտիֆիկատորները, որոնք կազմված են միայն թվերից, համեմատվումեն թվայնորեն։ Տառեր և գծիկ պարունակող իդենտիֆիկատորները համեմատվում ենտառացի՝ ASCII աղյուսակի հերթականությամբ։ Թվային իդենտիֆիկատորները միշտունենում են ավելի ցածր կարգավիճակ, քան ոչ թվայինները։ Մինչթողարկումայինսիմվոլների մեծ քանակ ունեցող տարբերակը ունենում է ավելի բարձր կարգավիճակ, երբհամեմատվող իդենտիֆիկատորները նույնն են․ օրինակ՝ 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։
<valid semver> ::= <version core> | <version core> "-" <pre-release> | <version core> "+" <build> | <version core> "-" <pre-release> "+" <build><version core> ::= <major> "." <minor> "." <patch><major> ::= <numeric identifier><minor> ::= <numeric identifier><patch> ::= <numeric identifier><pre-release> ::= <dot-separated pre-release identifiers><dot-separated pre-release identifiers> ::= <pre-release identifier> | <pre-release identifier> "." <dot-separated pre-release identifiers><build> ::= <dot-separated build identifiers><dot-separated build identifiers> ::= <build identifier> | <build identifier> "." <dot-separated build identifiers><pre-release identifier> ::= <alphanumeric identifier> | <numeric identifier><build identifier> ::= <alphanumeric identifier> | <digits><alphanumeric identifier> ::= <non-digit> | <non-digit> <identifier characters> | <identifier characters> <non-digit> | <identifier characters> <non-digit> <identifier characters><numeric identifier> ::= "0" | <positive digit> | <positive digit> <digits><identifier characters> ::= <identifier character> | <identifier character> <identifier characters><identifier character> ::= <digit> | <non-digit><non-digit> ::= <letter> | "-"<digits> ::= <digit> | <digit> <digits><digit> ::= "0" | <positive digit><positive digit> ::= "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"<letter> ::= "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),որի անունն է՝ «Firetruck»։ Նրա աշխատանքի համար անհրաժեշ է Սեմանտիկ Տարբերակումովթողարկվող «Ladder» փեքիջը։ Երբ Firetruck֊ը ստեղծվել էր, Ladder֊ի տարբերակիհամարն էր՝ 3.1.0։ Քանի որ Firetruck֊ը օգտագործում է Ladder֊ի 3.1.0 տարբերակիֆունկցիոնալը, դուք հանգիստ կարող եք հայտարարել կախվածությունը Ladder֊ի 3.1.0տարբերակից, բայց ոչ ավել քան 4.0.0։ Երբ դուրս գա Ladder֊ի 3.2.0 տարբերակը, դուքհաստատ կիմանաք, որ այն համատեղելի է ձեր ծրագրի հետ և կարող եք հանգիստ ինտեգրելայն։
Որպես պատասխանատու ծրագրավորող՝ դուք իհարկե կցանկանաք վստահ լինել, որ բոլորթարմացումները աշխատում են այնպես ինչպես հայտարարվել է։ Իրական աշխարհում միշտխառնաշփոթ է, և ոչինչ չի կարելի անել դրա հետ, բացի ուշադիր լինելուց։ Սեմանտիկտարբերակման միջոցով դուք կարող եք թողարկել ձեր ծրագրային ապահովման նորտարբերակներ և թարմացումներ չմտածելով կախվածությունների մասին և պահպանել ձերժամանակը և նյարդերը։
Եթե այս ամենը գայթակղիչ է թվում ձեզ, այն ամենը ինչ ձեզ անհրաժեշտ է՝ սկսելօգտագործել Սեմանտիկ տարբերակումը, հայտարարել դրա մասին և հետևել կանոններին։ Նշեքայս կայքի հղումը ձեր README֊ում և օգտագործողները կիմանան այս կանոնների մասին։
Ամենահեշտ լուծումը աշխատանքը 0.1.0 տարբերակի թողարկումով սկսելն է և հետագայումամեն հաջորդ թողարկման համար ՄԻՆՈՐ տարբերակի համարը մեծացնելը։
Եթե ձեր ծրագրային ապահովումը արդեն օգտագործվում է պրոդաքշնում, ամենայնհավանականությամբ արդեն պետք է թողարկել 1.0.0 տարբերակը։ Եթե դուք ունեք ստաբիլAPI, որը ունի օգտագործողներ, տարբերակի համարը պետք է լինի 1.0.0։ Եթեանհանգստանում եք հետ համատեղելիության մասին, ամենայն հավանականությամբ ձերծրագրային ապահովման տարբերակի համարը արդեն պետք է լինի 1.0.0։
Երբ ՄԱԺՈՐ տարբերակի համարը 0 է, դա արդեն իսկ ենթադրում է արագ ծրագրավորում։ Եթեդուք փոփոխեք API֊ը ամեն օր, ապա պետք է լինեք 0.y.z տարբերակի վրա, կամ առանձինճյուղի (branch) վրա աշխատեք հաջորդ ՄԱԺՈՐ տարբերակի թողարկման համար։
Սա ավելի շատ պատասխանատվության և հեռատեսության խնդիր է։ Ծրագրային ապահովման հետհամատեղելիությունը խախտող փոփոխությունները աննշան չեն, քանի որ դրա արդյունքումթարմացումները կարող են շատ թանկ արժենալ։ Հետ համատեղելիությունը խախտողփոփոխությունների թողարկումը տարբերակի ՄԱԺՈՐ համարի ավելացմամբ, նշանակում է՝ դուքպետք է մտածեք ձեր փոփոխությունների հետևանքների մասին և հաշվի առնեք գին֊օգուտհարաբերակցությունը։
Որպես պրոֆեսիոնալ ծրագրավորող ձեր պատասխանատվությունն է ճիշտ դոկումենտացնելծրագրային ապահովումը, որը նախատեսված է ուրիշների օգտագործման համար։ Ծրագրայինապահովման բարդության կարգավորումը նրա արդյունավետության պահպանման կարևոևագույնկետերից մեկն է։ Եթե ոչ մեկը չգիտի, թե ինչպես օգտագործել ձեր ծրագրայինապահովումը, կամ որ մեթոդի կանչն է անվտանգ, ինչպես պետք է նրանք օգտագործեն այն։Երկարաժամկետ հեռանկարով Սեմանտիկ Տարբերակումը, համառ և կոշտ դիրքը որակովշարադրված փաբլիք API֊ի նկատմամբ կնպաստեն ամենքի և ամեն ինչի ճիշտ և համակարգվածաշխատելուն։
Հենց որ դուք հասկացաք, որ խախտել եք Սեմանտիկ Տարբերակման սպեցիֆիկացիան, ուղղեքսխալը և թողարկեք նոր ՄԻՆՈՐ տարբերակ, որը լուծում է խնդիրը և վերականգնում հետհամատեղելիությունը։ Նույնիսկ նման դեպքերում անընդունելի է արդեն թողարկվածտարբերակներում փոփոխությունների իրականացումը։ Եթե անհրաժեշտ է, նշեքդոկումենտացիայում և տեղյակ պահեք օգտագործողներին հետ համատեղելիության ևտարբերակման հերթականության խախտման մասին։
Դա կարող է դիտարկվել որպես հետ համատեղելի փոփոխություն, քանի որ այն չի ազդումփաբլիք API֊ի վրա։ Ծրագրային ապահովումը, որը ակնհայտորեն ունի նույնկախվածությունները, ինչ փեքիջը, պետք է ունենա իր սեփական կախվածություններիսպեցիֆիկացիան, և հեղինակը տեղյակ կլինի ի հայտ եկած կոնֆլիկտների մասին։ Արդյոքտվյալ փոփոխությունները ՄԱԺՈՐ, թե ՓԱԹՉ մակարդակի են, կախված է նրանից, թե դուքփոխել եք ձեր կախվածությունները սխալներ ուղղելու, թե՞ նոր ֆունկցիոնալ ինտեգրելուհամար։ Երկրորդ դեպքում, որպես կանոն ավելանում է որոշակի քանակով կոդ և որպեսհետևանք մեծանում է տարբերակի ՄԻՆՈՐ համարը։
Որոշումը ձերն է։ Եթե դուք ունեք օգտագործողների մեծ խումբ, որը կկանգնի փաբլիքAPI֊ի նախկին ֆունկցիոնալի վերականգման փաստի առաջ, ուրեմն ճիշտ կլինի թողարկել նորտարբերակ ՄԱԺՈՐ համարի մեծացումով։ Չնայած նրան, որ այն պարունակում է միայն ՓԱԹՉմակարդակի փոփոխություններ, հիշեք՝ ըստ Սեմանտիկ Տարբերակման սպեցիֆիկացիայիտարբերակի համարները մեծացվում են սպեցիֆիկացիային համաձայն։ Եթե այդփոփոխությունները կարևոր են ձեր օգտագործողների համար, օգտագործեք տարբերակի համարընրանց տեղյակ պահելու համար։
Որոշ ֆունկցիոնալի հնանալը սովորական երևույթ է և ծրագրային ապահովմանստեղծման/մշակման ընթացքում հաճախ պարտադիր է առաջընթացի համար։ Երբ դուք հնացած եքհայտարարում, փաբլիք API֊ի ինչ֊որ հատված, դուք պետք է երկու բան անեք․ նախթարմացնեք ձեր դոկումենտացիան և տեղեկացնեք օգտագործողներին փոփոխության մասին (1),և ապա թողարկեք նոր ՄԻՆՈՐ տարբերակ՝ նշում կատարելով հնացած ֆունկցիոնալի մասին(2)։ Մինչ դուք ամբողջովին կջնջեք հնացած ֆունկցիոնալը, հաջորդ ՄԱԺՈՐ թողարկմանժամանակ պետք է լինի առնվազն մեկ ՄԻՆՈՐ թողարկում, որը պարունակում է տեղեկությունֆունկցիոնալի հնացած հայտարարվելու մասին, որպեսզի օգտագործողները հեշտությամբանցնեն նոր API֊ի։
Ոչ, բայց եղեք խելամիտ։ Եթե տարբերակի համարի երկարությունը 255 սիմվոլ է,հավանաբար դա չափազանց է։ Բացի դրանից որոշ համակարգեր կարող են ունենալ իրենցսեփական սահմանափակումները տարբերակի համարի երկարության վրա։
Ոչ, «v1.2.3»֊ը տարբերակի սեմանտիկ համար չի համարվում։ Ամեն դեպքում «v» տառըսեմանտիկ տարբերակի առջևում դնելը ընդունված երևույթ է (անգլերենում) տարբերակիհամարը ընդգծելու համար։ «v» հապավման օգտագործումը «version» բառի փոխարենտարածված պրակտիկա է տարբերակների կարգավորման (version control) մեջ: Օրինակ՝git tag v1.2.3 -m "Release version 1.2.3"․ այստեղ «v1.2.3»֊ը թեգի անուն է, ևսեմանտիկ տարբերակը «1.2.3» է։
Կա երկու եղանակ.
Տես՝https://regex101.com/r/Ly7O1x/3/
^(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<prerelease>(?: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<buildmetadata>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$Տես՝https://regex101.com/r/vkijKf/1/
^(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-]+)*))?$Սեմանտիկ Տարբերակման սպեցիֆիկացիայի հեղինակն էԹոմ Պրեստոն-Վարները (Gravatar֊ի հիմնադիր ևGitHub֊ի համահիմնադիր)։
Եթե դուք ցանկանում եք որևէ մեկնաբանություն թողնել, խնդրում ենքGitHub֊ում հարց (issue) բացել։