[{"data":1,"prerenderedAt":1379},["ShallowReactive",2],{"NoscriptNav_XrRK2e2e8meJ0jKVGkb5ULGQDVi3UiFQ9nupAr7Yns":3,"\u002Freports\u002Ffrom-zerover-to-semver-a-comprehensive-list-of-versioning-schemes-in-open-source":8},["Island",4],{"key":5,"result":6},"NoscriptNav_XrRK2e2e8meJ0jKVGkb5ULGQDVi3UiFQ9nupAr7Yns",{"head":7},{},{"id":9,"title":10,"authors":11,"body":13,"canonicalUrl":1365,"canonicalWebsiteName":1366,"category":1367,"date":1368,"description":1369,"extension":1370,"featured":1371,"fullWidthLayout":1371,"image":1372,"imageAlt":1372,"location":1372,"meta":1373,"metaImage":1372,"navigation":1374,"path":1375,"seo":1376,"stem":1377,"venue":1372,"venueUrl":1372,"__hash__":1378},"reports\u002Freports\u002Ffrom-zerover-to-semver-a-comprehensive-list-of-versioning-schemes-in-open-source.md","From ZeroVer to SemVer: A List of Versioning Schemes in Open Source",[12],"andrew",{"type":14,"value":15,"toc":1342},"minimark",[16,20,37,46,54,77,80,89,97,107,110,147,156,164,167,170,178,186,189,192,201,209,212,230,233,242,250,258,261,281,284,293,301,304,323,326,338,341,344,353,361,367,376,398,401,404,413,421,430,450,453,462,470,479,496,502,505,514,522,527,534,551,557,565,570,590,593,602,610,616,619,624,667,672,689,704,712,715,720,726,733,738,758,761,775,783,789,795,805,827,833,842,850,856,864,878,882,910,915,934,941,955,963,975,982,1028,1031,1042,1051,1055,1078,1080,1145,1159,1167,1172,1178,1201,1204,1218,1237,1245,1255,1262,1279,1282,1291,1294,1305,1308],[17,18,19],"p",{},"You might assume Semantic Versioning (SemVer) is the only real game in town but versioning in open source is far messier and more diverse than that. Across different ecosystems, maintainers have proposed and adopted a wide range of alternative schemes, from the satirical to the pragmatic. This post is a catalogue of the many versioning approaches that exist in the wild today—from ZeroVer to SemVer and beyond.",[17,21,22,23,30,31,36],{},"If you know of a versioning scheme that's missing from this list, I'd love to hear about it. You can reach me on ",[24,25,29],"a",{"href":26,"rel":27},"https:\u002F\u002Fmastodon.social\u002F@andrewnez",[28],"nofollow","Mastodon"," or open a pull request on ",[24,32,35],{"href":33,"rel":34},"https:\u002F\u002Fgithub.com\u002Fandrew\u002Fnesbitt.io\u002Fblob\u002Fmaster\u002F_posts\u002F2024-06-24-from-zerover-to-semver-a-comprehensive-list-of-versioning-schemes-in-open-source.md",[28],"GitHub",".",[38,39,41],"h2",{"id":40},"semver",[24,42,45],{"href":43,"rel":44},"https:\u002F\u002Fsemver.org\u002F",[28],"SemVer",[17,47,48,49,53],{},"Semantic Versioning (SemVer) is probably the most widely used and often assumed default versioning scheme in open source software. It follows the format ",[50,51,52],"code",{},"MAJOR.MINOR.PATCH",", where:",[55,56,57,65,71],"ul",{},[58,59,60,64],"li",{},[61,62,63],"strong",{},"MAJOR"," version increments indicate incompatible API changes,",[58,66,67,70],{},[61,68,69],{},"MINOR"," version increments add functionality in a backward-compatible manner,",[58,72,73,76],{},[61,74,75],{},"PATCH"," version increments make backward-compatible bug fixes.",[17,78,79],{},"This scheme provides a clear and predictable way to manage and communicate changes in software projects.",[17,81,82,83,88],{},"Originally proposed by ",[24,84,87],{"href":85,"rel":86},"https:\u002F\u002Ftom.preston-werner.com\u002F",[28],"Tom Preston-Werner"," in 2010, SemVer has since become the de facto standard for versioning in the open source community, used by many package managers and repositories, including npm, RubyGems, and Cargo.",[38,90,92],{"id":91},"calver",[24,93,96],{"href":94,"rel":95},"https:\u002F\u002Fcalver.org\u002F",[28],"CalVer",[17,98,99,102,103,106],{},[61,100,101],{},"Calendar Versioning (CalVer)"," is a versioning scheme that uses a date-based version number, typically in the format ",[50,104,105],{},"YYYY.MM.DD",". This scheme is based on the idea that version numbers should be human-readable and easy to understand, providing a clear indication of when a release was made.",[17,108,109],{},"CalVer offers multiple calendar-based formats to suit different project needs:",[55,111,112,117,123,129,135,141],{},[58,113,114,116],{},[61,115,105],{},": Full date (e.g., 2021.03.22) indicating the exact release day.",[58,118,119,122],{},[61,120,121],{},"YYYY.MM",": Year and month (e.g., 2021.03) for monthly releases.",[58,124,125,128],{},[61,126,127],{},"YYYY.0M.DD",": Zero-padded month and day (e.g., 2021.03.05) for consistency in sorting.",[58,130,131,134],{},[61,132,133],{},"YY.0M.DD",": Short year, zero-padded month, and day (e.g., 21.03.05) for compactness.",[58,136,137,140],{},[61,138,139],{},"YYYY.WW",": Year and week number (e.g., 2021.12) for weekly releases.",[58,142,143,146],{},[61,144,145],{},"YY.0W",": Short year and zero-padded week (e.g., 21.05) for a simpler weekly format.",[17,148,149,150,155],{},"CalVer was proposed by ",[24,151,154],{"href":152,"rel":153},"https:\u002F\u002Fsedimental.org\u002F",[28],"Mahmoud Hashemi"," in March 2016.",[38,157,159],{"id":158},"zerover",[24,160,163],{"href":161,"rel":162},"https:\u002F\u002F0ver.org\u002F",[28],"ZeroVer",[17,165,166],{},"ZeroVer is a satirical versioning scheme where the version number always starts with 0. This convention humorously suggests that software is perpetually in its initial development stages, indicating that it is not yet stable and that APIs are subject to change. Versions might look like 0.1.0, 0.2.0, and so on.",[17,168,169],{},"While it’s meant as a joke, many projects unintentionally fall into ZeroVer compatibility simply because they have never made the jump to 1.0.0. This can also serve to set expectations about the software’s maturity and stability during early development.",[17,171,172,173,177],{},"Version 0.0.1 of ZeroVer was published by ",[24,174,154],{"href":175,"rel":176},"https:\u002F\u002Fgithub.com\u002Fmahmoud\u002F",[28]," on 2018-04-01.",[38,179,181],{"id":180},"effver",[24,182,185],{"href":183,"rel":184},"https:\u002F\u002Fjacobtomlinson.dev\u002Feffver\u002F",[28],"EffVer",[17,187,188],{},"Intended Effort Versioning (EffVer) is a versioning scheme that, instead of quantifying the orthogonality of a change, tries to quantify the intended work required to adopt the change. EffVer doesn’t make a distinction between bug fixes, enhancements, and features, as releases often include all of these elements.",[17,190,191],{},"Instead, it focuses solely on the effort required for existing users to adopt new versions. The version number reflects the effort needed, with higher numbers indicating more significant changes and potentially greater effort to adopt. This approach helps users better plan for updates by understanding the impact on their workflow.",[17,193,194,195,200],{},"EffVer was proposed by ",[24,196,199],{"href":197,"rel":198},"https:\u002F\u002Fjacobtomlinson.dev\u002F",[28],"Jacob Tomlinson"," in January 2024 as an alternative to SemVer and CalVer, aiming to provide a more user-centric approach to versioning.",[38,202,204],{"id":203},"romver",[24,205,208],{"href":206,"rel":207},"https:\u002F\u002Fgithub.com\u002Fromversioning\u002Fromver",[28],"RomVer",[17,210,211],{},"Romantic Versioning (RomVer) is a versioning scheme based on Semantic Versioning (SemVer) but attempts to extract the “versioning spec” from real-world usage of software versions, such as those in Node, Rails, PHP, jQuery, NPM, and the Linux Kernel. RomVer follows the format HUMAN.MAJOR.MINOR, where:",[55,213,214,220,225],{},[58,215,216,219],{},[61,217,218],{},"HUMAN"," is a memorable, human-readable name or word that encapsulates the essence or milestone of the release,",[58,221,222,224],{},[61,223,63],{}," indicates significant, potentially backward-incompatible changes,",[58,226,227,229],{},[61,228,69],{}," denotes smaller, backward-compatible updates and bug fixes.",[17,231,232],{},"RomVer seeks to enforce some rules to make software versioning predictable and straightforward, helping users better understand the impact of updates. By using human-readable names, it provides a more intuitive way to identify and recall different versions, aligning closely with real-world practices observed in various software projects.",[17,234,235,236,241],{},"RomVer was proposed by ",[24,237,240],{"href":238,"rel":239},"https:\u002F\u002Fweb.archive.org\u002Fweb\u002F20160313185630\u002Fhttp:\u002F\u002Fblog.legacyteam.info\u002F2015\u002F12\u002Fromver-romantic-versioning\u002F",[28],"Daniel V from the Legacy Blog crew"," in 2015.",[17,243,244,245,36],{},"The term as also used by Jeremy Ashkenas in 2012 in the context of ",[24,246,249],{"href":247,"rel":248},"https:\u002F\u002Fgithub.com\u002Fjashkenas\u002Fbackbone\u002Fissues\u002F2888#issuecomment-29076249",[28],"Backbone.js",[38,251,253],{"id":252},"sentimental-versioning",[24,254,257],{"href":255,"rel":256},"https:\u002F\u002Fgithub.com\u002Fdominictarr\u002Fsentimental-versioning",[28],"Sentimental Versioning",[17,259,260],{},"Sentimental Versioning takes a whimsical and highly personal approach to versioning. Unlike SemVer, which has a formal specification, Sentimental Versioning provides a guide with some playful suggestions. Key aspects include:",[55,262,263,269,275],{},[58,264,265,268],{},[61,266,267],{},"Creativity and Originality",": You should not copy another sentimental versioning system. Instead, create something unique and original.",[58,270,271,274],{},[61,272,273],{},"Personal Meaning",": The version number must be meaningful to you, the author.",[58,276,277,280],{},[61,278,279],{},"Flexibility",": You may explain the system you create if the beauty is enhanced by understanding it, or you may improvise new numbers based on your mood on that day.",[17,282,283],{},"Sentimental Versioning encourages a deeply personal and creative expression through version numbers, making each version a reflection of the author’s sentiments and individuality.",[17,285,286,287,292],{},"Sentimental Versioning was proposed by ",[24,288,291],{"href":289,"rel":290},"https:\u002F\u002Fdominictarr.com\u002F",[28],"Dominic Tarr"," in August 2014.",[38,294,296],{"id":295},"hashver",[24,297,300],{"href":298,"rel":299},"https:\u002F\u002Fminiscruff.github.io\u002Fhashver\u002F",[28],"HashVer",[17,302,303],{},"Hash Versioning (HashVer) is perfect if you are publishing very frequently. The HashVer format consists of 3 or 4 values separated by a period:",[305,306,307,310,313,320],"ol",{},[58,308,309],{},"Full year (printf(\"%Y\"))",[58,311,312],{},"Zero padded month (printf(\"%m\"))",[58,314,315,319],{},[316,317,318],"span",{},"Optional"," Zero padded day (printf(\"%d\"))",[58,321,322],{},"10+ characters of the current source control commit’s hash",[17,324,325],{},"Examples:",[55,327,328,333],{},[58,329,330],{},[50,331,332],{},"2020.01.67092445a1abc",[58,334,335],{},[50,336,337],{},"2019.07.21.3731a8be0f1a8",[17,339,340],{},"HashVer allows for frequent and precise versioning by incorporating both the release date and a unique identifier from the source control system. This makes it easy to track specific builds and changes over time.",[17,342,343],{},"Because commit hashes are random, additional granularity like days or a CI build index ensures proper ordering when releasing frequently. This approach allows for precise and traceable versioning by combining the release date with a unique commit identifier.",[17,345,346,347,352],{},"HashVer was proposed by ",[24,348,351],{"href":349,"rel":350},"https:\u002F\u002Fgithub.com\u002Fminiscruff",[28],"miniscruff"," in 2020.",[38,354,356],{"id":355},"gitdate",[24,357,360],{"href":358,"rel":359},"https:\u002F\u002Ftaylorbrazelton.com\u002F2022\u002F06\u002F06\u002F2022-06-06-bye-bye-semantic-versioning-say-hello-to-gitdate\u002F",[28],"GitDate",[17,362,363,366],{},[61,364,365],{},"GitDate Versioning"," is similar to HashVer, addressing issues with Semantic Versioning by using the commit date from a Git repository. This provides clear and precise tracking of changes.",[17,368,369,372,373],{},[61,370,371],{},"Format",": ",[50,374,375],{},"year.month.day.git-short-code",[55,377,378],{},[58,379,380,381],{},"Examples:\n",[55,382,383,388,393],{},[58,384,385],{},[50,386,387],{},"2021.03.22.d31d336",[58,389,390],{},[50,391,392],{},"2021.03.31.44cf59b1",[58,394,395],{},[50,396,397],{},"2022.02.14.2c52a964",[17,399,400],{},"GitDate indicates the release date of each version for easy identification of when a version was created. It allows quick lookup of changes using git compare and provides visibility into the last release for infrastructure teams. Even without git tags, specific versions can be cloned using the format.",[17,402,403],{},"However, multiple builds on the same day may require git repository access to determine the order. Additionally, it allows customers to see when the software was last updated.",[17,405,406,407,412],{},"GitDate was proposed by ",[24,408,411],{"href":409,"rel":410},"https:\u002F\u002Ftaylorbrazelton.com\u002F",[28],"Taylor Brazelton"," in June 2022.",[38,414,416],{"id":415},"pragver",[24,417,420],{"href":418,"rel":419},"https:\u002F\u002Fgithub.com\u002Fseveibar\u002Fpragmaticversioning",[28],"PragVer",[17,422,423,426,427,53],{},[61,424,425],{},"Pragmatic Versioning"," optimizes for communicating changes to package consumers while retaining simple semantics for package maintainers. The format is ",[50,428,429],{},"BIGRELEASE.ANNOUNCE.INCREMENT",[55,431,432,438,444],{},[58,433,434,437],{},[61,435,436],{},"BIGRELEASE"," indicates major updates or significant milestones controlled by the package author.",[58,439,440,443],{},[61,441,442],{},"ANNOUNCE"," communicates notable announcements or changes.",[58,445,446,449],{},[61,447,448],{},"INCREMENT"," is a smaller, incremental update for every contribution.",[17,451,452],{},"Pragmatic Versioning addresses the challenges faced by package authors, enabling them to maintain old versions and release new ones efficiently. It helps communicate what will be maintained, how to get the most appropriate version, and allows for automatic releases without explicitly labeling each change. This approach ensures clear expectations and effective communication with the user community.",[17,454,455,456,461],{},"Pragmatic Versioning was proposed by ",[24,457,460],{"href":458,"rel":459},"https:\u002F\u002Fseve.blog\u002F",[28],"Severin Ibarluzea"," in December 2023.",[38,463,465],{"id":464},"wendtver",[24,466,469],{"href":467,"rel":468},"https:\u002F\u002Fwendtver.org\u002F",[28],"WendtVer",[17,471,472,474,475,478],{},[61,473,469],{}," is a tongue-in-cheek versioning system designed to minimize the thought required for version increments. Starting at ",[50,476,477],{},"0.0.0",", every commit increments the version number following these rules:",[55,480,481,486,491],{},[58,482,483,485],{},[61,484,75],{}," version increments on every commit.",[58,487,488,490],{},[61,489,69],{}," version increments when the next PATCH would be 10, rolling PATCH over to 0.",[58,492,493,495],{},[61,494,63],{}," version increments when the next MINOR would be 10, rolling MINOR over to 0.",[17,497,498,499,501],{},"Additional labels for pre-release and build metadata are not available as extensions to the ",[50,500,52],{}," format.",[17,503,504],{},"This system, while creating chaotic and meaningless version numbers, makes it easy to predict the next version. WendtVer serves as a humorous alternative to Semantic Versioning, emphasizing simplicity over rational versioning practices.",[17,506,507,508,513],{},"WendtVer was proposed by ",[24,509,512],{"href":510,"rel":511},"https:\u002F\u002Fbrianwendt.com\u002F",[28],"Brian Wendt"," in August 2018",[38,515,517],{"id":516},"solover",[24,518,521],{"href":519,"rel":520},"https:\u002F\u002Fbeza1e1.tuxen.de\u002FSoloVer",[28],"SoloVer",[17,523,524,526],{},[61,525,521],{}," is a simple and expressive versioning specification that uses a single number with an optional postfix.",[17,528,529,372,531],{},[61,530,371],{},[50,532,533],{},"\u003Cversion_number>[\u003Cpostfix>]",[55,535,536,542],{},[58,537,538,541],{},[61,539,540],{},"version_number",": A single integer, starting at 0.",[58,543,544,547,548,36],{},[61,545,546],{},"postfix",": Optional, matching regex ",[50,549,550],{},"[+-][A-Za-z0-9_]+",[17,552,553,556],{},[61,554,555],{},"Rules",":",[55,558,559,562],{},[58,560,561],{},"Increment the version number for each new release.",[58,563,564],{},"Postfixes can be added for extra context.",[17,566,567,556],{},[61,568,569],{},"Precedence",[55,571,572,575,581,587],{},[58,573,574],{},"Higher numbers follow lower numbers.",[58,576,577,580],{},[50,578,579],{},"+"," postfixes come after no postfix (for hotfixes).",[58,582,583,586],{},[50,584,585],{},"-"," postfixes come before no postfix (for pre-releases).",[58,588,589],{},"Postfixes are sorted alphanumerically; longer ones come last.",[17,591,592],{},"SoloVer does not communicate \"backward compatibility\" and focuses on simplicity and expressiveness, leaving compatibility documentation and testing to the provider and user.",[17,594,595,596,601],{},"SoloVer was proposed by ",[24,597,600],{"href":598,"rel":599},"https:\u002F\u002Fbeza1e1.tuxen.de\u002F",[28],"beza1e1"," in March 2024.",[38,603,605],{"id":604},"breakver",[24,606,609],{"href":607,"rel":608},"https:\u002F\u002Fwww.taoensso.com\u002Fbreak-versioning",[28],"BreakVer",[17,611,612,615],{},[61,613,614],{},"Break Versioning (BreakVer)"," aims to fix several issues identified with Semantic Versioning (SemVer). BreakVer addresses the complexity of SemVer's lengthy specification and its lack of distinction between major and minor breakages.",[17,617,618],{},"BreakVer aims to be easy to follow strictly, making it more reliable in practice. It emphasizes the maximum potential impact of version updates, ensuring clear communication about the safety of upgrades.",[17,620,621,556],{},[61,622,623],{},"BreakVer Specification",[55,625,626],{},[58,627,628,372,630,633],{},[61,629,371],{},[50,631,632],{},"\u003Cmajor>.\u003Cminor>.\u003Cnon-breaking>[-\u003Coptional-qualifier>]",[55,634,635,641,647,653],{},[58,636,637,640],{},[61,638,639],{},"major",": Major breaking changes or significant non-breaking changes.",[58,642,643,646],{},[61,644,645],{},"minor",": Minor breaking changes or minor non-breaking changes.",[58,648,649,652],{},[61,650,651],{},"non-breaking",": Strictly no breaking changes.",[58,654,655,658,659,662,663,666],{},[61,656,657],{},"optional-qualifier",": Tags like ",[50,660,661],{},"-alpha1",", ",[50,664,665],{},"-RC2",", etc.",[17,668,669,556],{},[61,670,671],{},"Version Bumps",[55,673,674,679,684],{},[58,675,676,678],{},[61,677,651],{},": Always a safe upgrade.",[58,680,681,683],{},[61,682,645],{},": Check the CHANGELOG for minor breakages.",[58,685,686,688],{},[61,687,639],{},": Check the CHANGELOG for major breakages.",[17,690,691,692,697,698,703],{},"BreakVer was proposed by ",[24,693,696],{"href":694,"rel":695},"https:\u002F\u002Fwww.taoensso.com\u002F",[28],"Peter Taoussanis"," in August 2015 as part of the ",[24,699,702],{"href":700,"rel":701},"https:\u002F\u002Fgithub.com\u002Ftaoensso\u002Fencore",[28],"encore"," clojure library.",[38,705,707],{"id":706},"explicit-versioning",[24,708,711],{"href":709,"rel":710},"https:\u002F\u002Fgithub.com\u002Fexadra37-versioning\u002Fexplicit-versioning",[28],"Explicit Versioning",[17,713,714],{},"Explicit Versioning:",[17,716,717,719],{},[61,718,711],{}," is a specification for developers who care about releasing software with clear, explicit announcements of intended breaking changes. It uses an extra required identifier to handle intentional incompatible changes.",[17,721,722,725],{},[61,723,724],{},"Specification Schema",":\nExplicit Versioning uses a schema composed of four identifiers, represented as:",[55,727,728],{},[58,729,730],{},[50,731,732],{},"Disruptive.Incompatible.Compatible.Fix[-Optional_Identifiers]",[17,734,735,556],{},[61,736,737],{},"Key Differences from SemVer",[55,739,740,746,752],{},[58,741,742,745],{},[61,743,744],{},"Isolation of Incompatible Releases",": Isolates any intentional incompatible release from other types of releases.",[58,747,748,751],{},[61,749,750],{},"Disruptive Situations",": The most left number is only incremented when a disruptive situation occurs in the software, not for minimal backward incompatible changes.",[58,753,754,757],{},[61,755,756],{},"Clarity and Precision",": Reduces ambiguity in the usage and interpretation of the versioning schema.",[17,759,760],{},"This approach ensures that any significant, intentional changes are clearly communicated, providing a more precise and unambiguous versioning system for developers and users.",[17,762,763,764,769,770,36],{},"Explicit Versioning was proposed by ",[24,765,768],{"href":766,"rel":767},"https:\u002F\u002Fexadra37.com\u002F",[28],"Paulo Renato"," in February 2017, more details can be found in the ",[24,771,774],{"href":772,"rel":773},"https:\u002F\u002Fmedium.com\u002Fsapioit\u002Fwhy-having-3-numbers-in-the-version-name-is-bad-92fc1f6bc73c",[28],"Announcement Post",[38,776,778],{"id":777},"zenver",[24,779,782],{"href":780,"rel":781},"https:\u002F\u002Fgithub.com\u002FNotAShelf\u002FZenVer\u002F",[28],"ZenVer",[17,784,785,788],{},[61,786,787],{},"Zen Versioning (ZenVer)"," is a revolutionary, simple, and straightforward versioning specification. Unlike Semantic Versioning, ZenVer demands nothing from the developer and less from the end-user. The idea is clear: number go up, software go new.",[790,791,792],"blockquote",{},[17,793,794],{},"Larger is greater, greater is larger. Larger number means better software.",[17,796,797,800,801,804],{},[61,798,799],{},"Specification",":\nGiven a version number ",[50,802,803],{},"VERSION",", increment the:",[55,806,807,812,817,822],{},[58,808,809,811],{},[50,810,803],{}," when you make incompatible API changes.",[58,813,814,816],{},[50,815,803],{}," when you add functionality in a backward-compatible manner.",[58,818,819,821],{},[50,820,803],{}," when you make backward-compatible bug fixes.",[58,823,824,826],{},[50,825,803],{}," when you change practically anything.",[17,828,829,830,832],{},"No additional labels, titles, or subtitles for pre-release and build metadata should be appended to the ",[50,831,803],{}," format. Such metadata can be used outside the version string but should be avoided in package meta information.",[17,834,835,836,841],{},"ZenVer was proposed by ",[24,837,840],{"href":838,"rel":839},"https:\u002F\u002Fgithub.com\u002FNotAShelf",[28],"NotAShelf"," in May 2024.",[38,843,845],{"id":844},"pvp",[24,846,849],{"href":847,"rel":848},"https:\u002F\u002Fpvp.haskell.org\u002F",[28],"PVP",[17,851,852,855],{},[61,853,854],{},"Package Versioning Policy (PVP)"," is a versioning scheme designed specifically for the Haskell ecosystem to manage package dependencies and ensure compatibility. It provides a formal specification for version numbers to help developers and users maintain and use Haskell packages effectively.",[17,857,858,372,861],{},[61,859,860],{},"Version Number Format",[50,862,863],{},"A.B.C",[55,865,866,872],{},[58,867,868,871],{},[61,869,870],{},"A.B",": Major version number.",[58,873,874,877],{},[61,875,876],{},"C",": Minor version number.",[17,879,880,556],{},[61,881,555],{},[305,883,884,893,901],{},[58,885,886,889,890,892],{},[61,887,888],{},"Breaking Changes",": If any entity is removed or altered in a way that could break compatibility, increment the major version (",[50,891,870],{},").",[58,894,895,898,899,892],{},[61,896,897],{},"Non-Breaking Changes",": If only new bindings, types, or classes are added without breaking existing functionality, increment the minor version (",[50,900,876],{},[58,902,903,906,907,909],{},[61,904,905],{},"Minor Updates",": For minor, non-breaking updates like documentation corrections, other components of the version may change, but ",[50,908,863],{}," can remain the same.",[17,911,912,556],{},[61,913,914],{},"Principles",[55,916,917,922,928],{},[58,918,919,921],{},[61,920,744],{},": Major version increments isolate incompatible changes, ensuring clarity for users about potential breaking changes.",[58,923,924,927],{},[61,925,926],{},"Disambiguation",": Clear rules reduce ambiguity in how versions are incremented.",[58,929,930,933],{},[61,931,932],{},"Consistency",": Ensures consistent dependency specifications to avoid build and compatibility issues.",[17,935,936,937,940],{},"PVP is specifically tailored to the Haskell ecosystem, differing from Semantic Versioning (SemVer) by not using a special meaning for ",[50,938,939],{},"0.x.y"," versions and not supporting version tags or build metadata.",[17,942,943,944,949,950,36],{},"PVP was proposed to the Haskell community by ",[24,945,948],{"href":946,"rel":947},"https:\u002F\u002Fgithub.com\u002FBulat-Ziganshin",[28],"Bulat Ziganshin"," in 2006, three years before SemVer, on the ",[24,951,954],{"href":952,"rel":953},"https:\u002F\u002Fmail.haskell.org\u002Fpipermail\u002Fhaskell\u002F2006-November\u002F018762.html",[28],"Haskell mailing list",[38,956,958],{"id":957},"floatver",[24,959,962],{"href":960,"rel":961},"https:\u002F\u002Falexshroyer.com\u002Fposts\u002F2024-07-01-FloatVer.html",[28],"FloatVer",[17,964,965,967,968,971,972,36],{},[61,966,962],{}," is a versioning scheme that uses non-negative IEEE754 32-bit floating point numbers in base-10 format. FloatVer is natively supported by the majority of programming languages, CPUs, and GPUs. Some example FloatVer version numbers are ",[50,969,970],{},"0.7"," and ",[50,973,974],{},"290.10008",[17,976,977,372,979],{},[61,978,860],{},[50,980,981],{},"breaking.nonbreaking",[55,983,984,990,996,1005,1011,1017,1022],{},[58,985,986,989],{},[61,987,988],{},"breaking",": incremented by 1 for backward-incompatible changes",[58,991,992,995],{},[61,993,994],{},"nonbreaking",": incremented for backward-compatible changes",[58,997,998,999,1001,1002,1004],{},"Purely ",[50,1000,994],{}," changes MUST NOT increment the ",[50,1003,988],{}," part of the number.",[58,1006,1007,1008,1010],{},"Breaking changes MAY change the ",[50,1009,994],{}," part of the number to any value.",[58,1012,1013,1014,36],{},"Leading and trailing zeros are ignored, except in the case of ",[50,1015,1016],{},"0.0",[58,1018,1019,1021],{},[50,1020,1016],{}," is the minimum version and starting point for all FloatVer projects.",[58,1023,1024,1027],{},[50,1025,1026],{},"340282346638528859811704183484516925440.0000000000000000"," is the largest possible version supported by FloatVer.",[17,1029,1030],{},"In the context of FloatVer, \"backward-compatible\" means:",[55,1032,1033,1036,1039],{},[58,1034,1035],{},"no semantic changes to existing functionality",[58,1037,1038],{},"an updated existing feature uses no more memory, time, or cores than its previous version",[58,1040,1041],{},"the software takes up no more than 1.5 times the space of the previous version",[17,1043,1044,1045,1050],{},"These rules ensure that nonbreaking versions permit safe automatic upgrades. FloatVer was proposed by ",[24,1046,1049],{"href":1047,"rel":1048},"https:\u002F\u002Fgithub.com\u002FhoosierEE\u002F",[28],"Alex Shroyer"," in July 2024.",[38,1052,1054],{"id":1053},"asymptover","AsymptoVer",[17,1056,1057,1059,1060,1065,1066,1077],{},[61,1058,1054],{}," – yes, I’ve just made up that name – is a peculiar, maybe even esoteric, versioning scheme.\nIt was popularized by ",[24,1061,1064],{"href":1062,"rel":1063},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FDonald_Knuth",[28],"Donald Knuth"," (see also ",[24,1067,1070,1073,1074],{"href":1068,"rel":1069},"https:\u002F\u002Fwww-cs-faculty.stanford.edu\u002F~knuth\u002Fabcde.html#bugs",[28],[61,1071,1072],{},"Errata"," on the book series ",[61,1075,1076],{},"Computers & Typesetting",").\nVersion numbers are decimal numbers that asymptotically approach a number with an infinite decimal expansion (usually an irrational number).",[17,1079,325],{},[55,1081,1082,1117],{},[58,1083,1084,1085,1090,1091,1096,1097,1100,1101,1104,1105,1104,1108,1111,1112,892],{},"Version numbers of ",[24,1086,1089],{"href":1087,"rel":1088},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FTeX",[28],"TeX","\napproach ",[24,1092,1095],{"href":1093,"rel":1094},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FArchimedes_constant",[28],"Archimedes’ constant",".\nThe scheme was adopted at version number ",[50,1098,1099],{},"3",", followed by version ",[50,1102,1103],{},"3.1",", then ",[50,1106,1107],{},"3.14",[50,1109,1110],{},"3.141",", and so on (see ",[24,1113,1116],{"href":1114,"rel":1115},"https:\u002F\u002Foeis.org\u002FA000796",[28],"entry A000796 in the OEIS",[58,1118,1084,1119,1090,1124,1129,1130,1133,1134,1104,1137,1111,1140,892],{},[24,1120,1123],{"href":1121,"rel":1122},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FMetafont",[28],"Metafont",[24,1125,1128],{"href":1126,"rel":1127},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FEuler%27s_number",[28],"Euler’s number",",\nstarting at ",[50,1131,1132],{},"2",", followed by ",[50,1135,1136],{},"2.7",[50,1138,1139],{},"2.71",[24,1141,1144],{"href":1142,"rel":1143},"https:\u002F\u002Foeis.org\u002FA001113",[28],"entry A001113 in the OEIS",[17,1146,1147,1148,971,1153,1158],{},"If you feel like joking: There are plenty irrational ",[24,1149,1152],{"href":1150,"rel":1151},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FAlgebraic_number",[28],"algebraic numbers",[24,1154,1157],{"href":1155,"rel":1156},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FTranscendental_number",[28],"transcendental numbers"," available.",[38,1160,1162],{"id":1161},"trunkver",[24,1163,1166],{"href":1164,"rel":1165},"https:\u002F\u002Ftrunkver.org\u002F",[28],"TrunkVer",[17,1168,1169,1171],{},[61,1170,1166],{}," is a versioning scheme designed for trunk-based development and continuous delivery pipelines. It automates version generation, embedding meaningful metadata about the build, such as timestamps and commit hashes. TrunkVer is structurally compatible with SemVer.",[17,1173,1174,1175],{},"Version Number Format: ",[50,1176,1177],{},"YYYYMMDDHHMMSS.0.0-gCOMMIT_HASH-BUILD_REF",[55,1179,1180,1187,1194],{},[58,1181,1182,1183,1186],{},"Timestamp: ",[50,1184,1185],{},"YYYYMMDDHHMMSS"," represents the build date and time in UTC.",[58,1188,1189,1190,1193],{},"Commit Hash: ",[50,1191,1192],{},"gCOMMIT_HASH"," is the short Git commit hash of the build.",[58,1195,1196,1197,1200],{},"Build Ref: ",[50,1198,1199],{},"BUILD_REF"," is a CI\u002FCD reference (e.g., pipeline ID or local for manual builds).",[17,1202,1203],{},"Key Features:",[55,1205,1206,1209,1212,1215],{},[58,1207,1208],{},"Automates versioning in trunk-based workflows, eliminating manual version debates.",[58,1210,1211],{},"Ensures each build is uniquely identifiable.",[58,1213,1214],{},"Supports traceability and auditing for compliance and debugging.",[58,1216,1217],{},"Compatible with existing SemVer tooling for a seamless transition.",[17,1219,1220,1221,971,1226,1231,1232,841],{},"TrunkVer was proposed as a practical solution for modern continuous integration and deployment environments. TrunkVer was proposed by ",[24,1222,1225],{"href":1223,"rel":1224},"https:\u002F\u002Fgithub.com\u002Fc089",[28],"Chris Klyk",[24,1227,1230],{"href":1228,"rel":1229},"https:\u002F\u002Fgithub.com\u002Frradczewski",[28],"Raimo Radczewski"," of ",[24,1233,1236],{"href":1234,"rel":1235},"https:\u002F\u002Fwww.crftd.tech",[28],"crafted. tech collective GmbH",[38,1238,1240],{"id":1239},"epoch-semver",[24,1241,1244],{"href":1242,"rel":1243},"https:\u002F\u002Fantfu.me\u002Fposts\u002Fepoch-semver",[28],"Epoch SemVer",[17,1246,1247,1249,1250,1254],{},[61,1248,1244],{}," extends Semantic Versioning by introducing an additional numeric prefix called an ",[1251,1252,1253],"em",{},"epoch",". This prefix is intended to handle situations where a project undergoes fundamental changes—like a full rewrite or rebrand—that traditional SemVer can't clearly express.",[17,1256,1257,372,1259],{},[61,1258,371],{},[50,1260,1261],{},"EPOCH:MAJOR.MINOR.PATCH",[55,1263,1264,1270],{},[58,1265,1266,1269],{},[61,1267,1268],{},"EPOCH",": Increments when a project resets or diverges in a way that breaks continuity with previous versions.",[58,1271,1272,1274,1275,1278],{},[61,1273,52],{},": Follows standard ",[24,1276,45],{"href":43,"rel":1277},[28]," rules.",[17,1280,1281],{},"The epoch helps clarify incompatible timelines and avoids confusion when version numbers otherwise might overlap or reset.",[17,1283,1284,1285,1290],{},"Epoch SemVer was proposed by ",[24,1286,1289],{"href":1287,"rel":1288},"https:\u002F\u002Fantfu.me\u002F",[28],"Anthony Fu"," in Jan 2025.",[1292,1293],"hr",{},[17,1295,1296,1297,1301,1302,36],{},"If you know of any other versioning schemes that should be on this list? Let me know on ",[24,1298,1300],{"href":26,"rel":1299},[28],"mastodon"," or submit a pull request to ",[24,1303,35],{"href":33,"rel":1304},[28],[17,1306,1307],{},"Some other versioning related links:",[55,1309,1310,1318,1326,1334],{},[58,1311,1312,1317],{},[24,1313,1316],{"href":1314,"rel":1315},"https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=oyLBGkS5ICk",[28],"Spec-ulation"," by Rich Hickey",[58,1319,1320,1325],{},[24,1321,1324],{"href":1322,"rel":1323},"https:\u002F\u002Fhynek.me\u002Farticles\u002Fsemver-will-not-save-you\u002F",[28],"SemVer will not save you"," by Hynek Schlawack",[58,1327,1328,1333],{},[24,1329,1332],{"href":1330,"rel":1331},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FSoftware_versioning",[28],"Software Versioning"," on Wikipedia",[58,1335,1336,1341],{},[24,1337,1340],{"href":1338,"rel":1339},"https:\u002F\u002Fsafjan.com\u002Fsoftware-versioning-schemes\u002F",[28],"Software Versioning Schemes"," by Krystian Safjan",{"title":1343,"searchDepth":1344,"depth":1344,"links":1345},"",2,[1346,1347,1348,1349,1350,1351,1352,1353,1354,1355,1356,1357,1358,1359,1360,1361,1362,1363,1364],{"id":40,"depth":1344,"text":45},{"id":91,"depth":1344,"text":96},{"id":158,"depth":1344,"text":163},{"id":180,"depth":1344,"text":185},{"id":203,"depth":1344,"text":208},{"id":252,"depth":1344,"text":257},{"id":295,"depth":1344,"text":300},{"id":355,"depth":1344,"text":360},{"id":415,"depth":1344,"text":420},{"id":464,"depth":1344,"text":469},{"id":516,"depth":1344,"text":521},{"id":604,"depth":1344,"text":609},{"id":706,"depth":1344,"text":711},{"id":777,"depth":1344,"text":782},{"id":844,"depth":1344,"text":849},{"id":957,"depth":1344,"text":962},{"id":1053,"depth":1344,"text":1054},{"id":1161,"depth":1344,"text":1166},{"id":1239,"depth":1344,"text":1244},"https:\u002F\u002Fnesbitt.io\u002F2024\u002F06\u002F24\u002Ffrom-zerover-to-semver-a-comprehensive-list-of-versioning-schemes-in-open-source","nesbitt.io","package-management","2024-06-24","A curated catalogue of versioning schemes used in open source software—from the conventional to the creative.","md",false,null,{},true,"\u002Freports\u002Ffrom-zerover-to-semver-a-comprehensive-list-of-versioning-schemes-in-open-source",{"title":10,"description":1369},"reports\u002Ffrom-zerover-to-semver-a-comprehensive-list-of-versioning-schemes-in-open-source","ON0LSx1H8tKbFgCGPuBUutTDN47cSbF0ChEeYWA9pas",1780596103389]