{"id":160578,"date":"2021-01-22T16:00:45","date_gmt":"2021-01-22T13:00:45","guid":{"rendered":"https:\/\/en.buradabiliyorum.com\/what-is-semantic-versioning-cloudsavvy-it\/"},"modified":"2021-01-22T16:00:45","modified_gmt":"2021-01-22T13:00:45","slug":"what-is-semantic-versioning-cloudsavvy-it","status":"publish","type":"post","link":"https:\/\/buradabiliyorum.com\/en\/what-is-semantic-versioning-cloudsavvy-it\/","title":{"rendered":"#What is Semantic Versioning? \u2013 CloudSavvy IT"},"content":{"rendered":"<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_85 counter-hierarchy ez-toc-counter ez-toc-custom ez-toc-container-direction\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Table of Contents<\/p>\n<label for=\"ez-toc-cssicon-toggle-item-6a3ab7c86e424\" class=\"ez-toc-cssicon-toggle-label\"><span class=\"\"><span class=\"eztoc-hide\" style=\"display:none;\">Toggle<\/span><span class=\"ez-toc-icon-toggle-span\"><svg style=\"fill: #dd3333;color:#dd3333\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #dd3333;color:#dd3333\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/span><\/label><input type=\"checkbox\"  id=\"ez-toc-cssicon-toggle-item-6a3ab7c86e424\" checked aria-label=\"Toggle\" \/><nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/buradabiliyorum.com\/en\/what-is-semantic-versioning-cloudsavvy-it\/#Major_Minor_and_Patch\" >Major, Minor and Patch<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/buradabiliyorum.com\/en\/what-is-semantic-versioning-cloudsavvy-it\/#Where_to_Start\" >Where to Start?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/buradabiliyorum.com\/en\/what-is-semantic-versioning-cloudsavvy-it\/#Maintaining_Older_Branches\" >Maintaining Older Branches<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/buradabiliyorum.com\/en\/what-is-semantic-versioning-cloudsavvy-it\/#Handling_Pre-Release_Packages\" >Handling Pre-Release Packages<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/buradabiliyorum.com\/en\/what-is-semantic-versioning-cloudsavvy-it\/#Conclusion\" >Conclusion<\/a><\/li><\/ul><\/nav><\/div>\n<p><strong>&#8220;#What is Semantic Versioning? \u2013 CloudSavvy IT&#8221;<\/strong><\/p>\n<div id=\"article-content-area\">\n<img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-9103\" src=\"https:\/\/www.cloudsavvyit.com\/thumbcache\/0\/0\/12e7db87b3dbd62082a1e94792342c6a\/p\/uploads\/2021\/01\/82725a39.jpg\" alt=\"Illustration showing different semantic versioning strings\" width=\"1602\" height=\"902\" onload=\"pagespeed.lazyLoadImages.loadIfVisibleAndMaybeBeacon(this);\" onerror=\"this.onerror=null;pagespeed.lazyLoadImages.loadIfVisibleAndMaybeBeacon(this);\"\/><\/p>\n<p>Semantic versioning is a formal convention for determining the version number of new software releases. The standard helps software users to understand the severity of changes in each new distribution.<\/p>\n<p>A project that uses semantic versioning will advertise a <strong>Major<\/strong>, <strong>Minor<\/strong> and <strong>Patch<\/strong> number for each release. The version string <code>1.2.3<\/code> indicates a <em>major<\/em> version of 1, a <em>minor<\/em> version of 2 and a patch number of <em>3<\/em>.<\/p>\n<p>Version numbers using this format are widely used by both software packages and end-user executables such as <a href=\"https:\/\/buradabiliyorum.com\/en\/category\/download-scripts-themes-apps\/\" data-internallinksmanager029f6b8e52c=\"9\" title=\"Download Scripts &amp; Themes &amp; Apps\" target=\"_blank\" rel=\"noopener\">app<\/a>s and <a href=\"https:\/\/buradabiliyorum.com\/en\/category\/game\/\" data-internallinksmanager029f6b8e52c=\"7\" title=\"Game\" target=\"_blank\" rel=\"noopener\">game<\/a>s. Not every project exactly follows the standard set out by <a rel=\"nofollow noopener\" target=\"_blank\" href=\"https:\/\/semver.org\/\">semver.org<\/a>.<\/p>\n<p>The specification was created to address the problems caused by inconsistent versioning practices among software packages used as dependencies. By \u201cpackage\u201d and \u201cdependency,\u201d we\u2019re referring to a library of code that\u2019s intended to be used within another software project and is distributed by a package manager such as <code>npm<\/code>, <code>composer<\/code> or <code>nuget<\/code>. This is the application of semantic versioning which we\u2019re considering within this article.<\/p>\n<h2 id=\"major-minor-and-patch\"><span class=\"ez-toc-section\" id=\"Major_Minor_and_Patch\"><\/span>Major, Minor and Patch<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>It\u2019s important to understand the meaning of the three components involved. Together, they chart a project\u2019s development journey and relate the end-user impact of each new release.<\/p>\n<ul>\n<li><strong>Major number<\/strong> \u2013 The major number indicates the current version of the package\u2019s public interface. This should be incremented every time you make a change that would require existing users of your package to update their own work.<\/li>\n<li><strong>Minor number<\/strong> \u2013 The minor number describes the current functional release of your software. This is incremented whenever you add a new feature but do not otherwise alter your package\u2019s interface. It communicates to users that a significant change has been made but the package remains fully backwards compatible with the previous minor number.<\/li>\n<li><strong>Patch number<\/strong> \u2013 The patch number gets incremented every time you make a minor change that neither impacts the public interface or overall functionality of your package. This is most commonly used for bug fixes. Consumers should always be able to update to the latest patch release without hesitation.<\/li>\n<\/ul>\n<p>The semantic versioning release structure is best modelled as a tree. At the top, you have your public interface changes, each of which result in a new major number. Every major <a href=\"https:\/\/buradabiliyorum.com\/en\/category\/watch-movies-tv-seriess\/\" data-internallinksmanager029f6b8e52c=\"8\" title=\"Watch Movies &amp; TV Series\" target=\"_blank\" rel=\"noopener\">series<\/a> has its own set of minor releases, where new functionality is added in a backwards compatible manner. Finally, minor releases may receive bug-fixing patches from time-to-time.<\/p>\n<h2 id=\"where-to-start\"><span class=\"ez-toc-section\" id=\"Where_to_Start\"><\/span>Where to Start?<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Most projects should use <code>1.0.0<\/code> as their initial version. You are publishing your first public interface and an initial unaltered set of functionality. You haven\u2019t yet had to create a patch, so the patch version is <code>0<\/code>.<\/p>\n<p>Let\u2019s now look at what happens as you make changes to your package. After your initial release, you receive a bug report from a user. When you release the fix, the correct version number will be <code>1.0.1<\/code>. Were you to then create another bug-fixing release, you\u2019d bump the patch number up to <code>1.0.2<\/code>.<\/p>\n<p>In the meantime, you\u2019ve also been working on an exciting new feature. It\u2019s entirely optional so users won\u2019t need to do anything to upgrade. You release this as <code>1.1.0<\/code> \u2013 a new functional series has been created and you haven\u2019t had to patch it yet. Unfortunately, bug reports soon come in and so <code>1.1.1<\/code> gets pushed out to your users.<\/p>\n<p>Several months on, you\u2019ve decided to refactor the entire project. Some of the functionality you used to offer has been removed or is now accessed through a consolidated interface. If you released this work, people using the current version of your package would have to make major alterations within their project. It\u2019s time for you to publish <code>2.0.0<\/code> into your package repository.<\/p>\n<h2 id=\"maintaining-older-branches\"><span class=\"ez-toc-section\" id=\"Maintaining_Older_Branches\"><\/span>Maintaining Older Branches<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Bumping a number within your version string doesn\u2019t create a point of no return. After publishing <code>1.1.1<\/code>, you might discover a bug which was also present in <code>1.0.2<\/code>. Using branches in your source control system, you could apply the patch to both version series. You\u2019d end up releasing <code>1.1.2<\/code> and <code>1.0.3<\/code>.<\/p>\n<p>Similarly, you might want to keep maintaining the <code>1.x<\/code> branch of your project despite having released <code>2.0.0<\/code>. It may feel strange to publish <code>1.1.2<\/code> after <code>2.0.1<\/code> but this is perfectly acceptable practice. Semantic versioning does not create a linear always-incrementing version number; instead, it is intended to be used as part of a branching development model that capitalises on the ease-of-patching offered by source control systems such as Git.<\/p>\n<p>Published versions must be immutable. Once you\u2019ve created a release, such as <code>2.4.3<\/code>, you cannot \u201cupdate\u201d it by simply pushing additional code under the same version string. You have to assign a new version number to each release, so users can always access each specific revision of your package.<\/p>\n<h2 id=\"handling-pre-release-packages\"><span class=\"ez-toc-section\" id=\"Handling_Pre-Release_Packages\"><\/span>Handling Pre-Release Packages<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Ordinarily, you always bump the major version of your project whenever a backwards incompatible change is introduced. When you\u2019re in a pre-launch state, your codebase may evolve very quickly, resulting in a slew of major versions being published.<\/p>\n<p>You can avoid this by advertising your project as <code>0.y.z<\/code> to begin with. Adopting <code>0<\/code> as your major version indicates that your package is unstable. The normal rules around backwards incompatible changes no longer apply, so you can publish new releases by incrementing the minor and patch numbers only. This means you can still use <code>1.0.0<\/code> to label the first \u201cfinished\u201d version of your software.<\/p>\n<p>You may also append extra \u201cidentifiers\u201d to the end of the version string, using a hyphen as the separator: <code>1.0.0-alpha.1<\/code>. You can use this to clearly denote alpha and beta variants. Similarly, you can include build metadata by appending it with the <code>+<\/code> character: <code>1.1.0-alpha.1+linux_x86<\/code>.<\/p>\n<h2 id=\"conclusion\"><span class=\"ez-toc-section\" id=\"Conclusion\"><\/span>Conclusion<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Making consistent use of semantic versioning helps users to have confidence in your project. They can clearly see how your codebase is evolving and whether they\u2019ll need to do work themselves to stay up-to-date.<\/p>\n<p>Advertising a semantic versioning string is essential when you publish to most popular package managers. Nonetheless, it\u2019s ultimately your decision which numbers you bump for each new release. Sticking to <a rel=\"nofollow noopener\" target=\"_blank\" href=\"https:\/\/semver.org\/\">the standard<\/a> clearly communicates your intentions to the community and minimises the risk of unintentionally breaking someone else\u2019s work.\n<\/div>\n<blockquote><p><strong><span style=\"color: #ff6600;\">If you liked the article, do not forget to share it with your friends. Follow us on\u00a0<span style=\"color: #ff0000;\"><a style=\"color: #ff0000;\" href=\"https:\/\/news.google.com\/publications\/CAAqBwgKMLG0nwswvr63Aw\" target=\"_blank\" rel=\"nofollow noopener noreferrer\">Google News<\/a><\/span>\u00a0too, click on the star and choose us from your favorites.<\/span><\/strong><\/p><\/blockquote>\n<blockquote>\n<p style=\"text-align: center;\">For forums sites go to <span style=\"color: #ff9900;\"><a style=\"color: #ff9900;\" href=\"https:\/\/forum.buradabiliyorum.com\/\" target=\"_blank\" rel=\"noopener\">Forum.BuradaBiliyorum.Com<\/a><\/span><\/strong><\/p>\n<\/blockquote>\n<blockquote>\n<p style=\"text-align: center;\"><strong>If you want to read more like this article, you can visit our <span style=\"color: #ff9900;\"><a style=\"color: #ff9900;\" href=\"https:\/\/en.buradabiliyorum.com\/technology\/\" target=\"_blank\" rel=\"noopener\">Technology category.<\/a><\/span><\/strong><\/p>\n<\/blockquote>\n<p><span style=\"color: black;\"><a style=\"color: #ff9900;\" href=\"https:\/\/www.cloudsavvyit.com\/9102\/what-is-semantic-versioning\/\" target=\"_blank\" rel=\"noopener\">Source<\/a><\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>&#8220;#What is Semantic Versioning? \u2013 CloudSavvy IT&#8221; Semantic versioning is a formal convention for determining the version number of new software releases. The standard helps software users to understand the severity of changes in each new distribution. A project that uses semantic versioning will advertise a Major, Minor and Patch number for each release. The&#8230;<\/p>\n","protected":false},"author":1,"featured_media":160579,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"fifu_image_url":"https:\/\/www.cloudsavvyit.com\/p\/uploads\/2021\/01\/82725a39.jpg","fifu_image_alt":"","footnotes":""},"categories":[18],"tags":[],"class_list":["post-160578","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technology"],"_links":{"self":[{"href":"https:\/\/buradabiliyorum.com\/en\/wp-json\/wp\/v2\/posts\/160578","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/buradabiliyorum.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/buradabiliyorum.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/buradabiliyorum.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/buradabiliyorum.com\/en\/wp-json\/wp\/v2\/comments?post=160578"}],"version-history":[{"count":0,"href":"https:\/\/buradabiliyorum.com\/en\/wp-json\/wp\/v2\/posts\/160578\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/buradabiliyorum.com\/en\/wp-json\/wp\/v2\/media\/160579"}],"wp:attachment":[{"href":"https:\/\/buradabiliyorum.com\/en\/wp-json\/wp\/v2\/media?parent=160578"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/buradabiliyorum.com\/en\/wp-json\/wp\/v2\/categories?post=160578"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/buradabiliyorum.com\/en\/wp-json\/wp\/v2\/tags?post=160578"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}