{"id":293,"date":"2014-08-16T15:23:42","date_gmt":"2014-08-16T15:23:42","guid":{"rendered":"http:\/\/blogs.gentoo.org\/lu_zero\/?p=293"},"modified":"2014-08-16T16:40:29","modified_gmt":"2014-08-16T16:40:29","slug":"libav-release-process","status":"publish","type":"post","link":"https:\/\/blogs.gentoo.org\/lu_zero\/2014\/08\/16\/libav-release-process\/","title":{"rendered":"Libav Release Process"},"content":{"rendered":"<p>Since the <a href=\"http:\/\/wiki.libav.org\/ReleaseProcess\">release document<\/a> is lacking here few notes on how it works, it will be updated soon =).<\/p>\n<h2>Versioning<\/h2>\n<p>Libav has separate version for each library provided. As usual the <strong>major<\/strong> version bump signifies an ABI-incompatible change, a <strong>minor<\/strong> version bump marks a specific feature introduction or removal.<br \/>\n It is made this way to let users leverage the pkgconf checks to require features instead of use a compile+link check.<br \/>\n The APIChange document details which version corresponds to which feature.<\/p>\n<p>The Libav global version number e.g. <strong>9.16<\/strong> provides mainly the following information:<\/p>\n<ul>\n<li>If the <b>major<\/b> number is updated the Libraries have ABI differences.\n<ul>\n<li> If the major number is <b>Even<\/b> API-incompatible changes should be expected, downstreams should follow the <a href=\"http:\/\/wiki.libav.org\/Migration\">migration<\/a> guide to update their code.<\/li>\n<li> If the major number is <b>Odd<\/b> no API-incompatible changes happened and a simple rebuild **must** be enough to use the new library.<\/li>\n<\/ul>\n<\/li>\n<li> If the <b>minor<\/b> number is updated that means that enough <b>bugfixes<\/b> piled up during the month\/2weeks period and a new point release is available.<\/li>\n<\/ul>\n<h2>Major releases<\/h2>\n<p>All the major releases start with a major version bump of all the libraries. This automatically enables new ABI incompatible code and disables old deprecated code. Later or within the same patch the preprocessor guards and the deprecated code gets removed.<\/p>\n<h3>Alpha<\/h3>\n<p>Once the major bump is committed the first <strong>alpha<\/strong> is tagged. Alphas live within the master branch, the codebase can still accept features updates (e.g. small new decoders or new demuxers) but the API and ABI cannot have incompatible changes till the next one or two major releases.<\/p>\n<h3>Beta<\/h3>\n<p>The first <strong>beta<\/strong> tag also marks the start of the new release branch.<br \/>\nFrom this point all the bugfixes that hit the master will be backported, no feature changes are accepted in the branch.<\/p>\n<h3>Release<\/h3>\n<p>The <strong>release<\/strong> is not different from a <strong>beta<\/strong>, it is still a tag in the release branch. The level of confidence nothing breaks is much higher though.<\/p>\n<h2>Point releases<\/h2>\n<p>Point releases are bugfix-only releases and they aim to provide seamless security updates.<\/p>\n<div class=\"alert alert-warning\">\nSince <b>most<\/b> bugs in Libav are security concerns users should update as soon the new release is out. We keep our <a href=\"http:\/\/fate.libav.org\">continuous integration system<\/a> monitoring all the release branches in addition to the master branch to be confident that backported bugfixes do not cause unexpected issues.\n<\/div>\n<h2>Libav 11<\/h2>\n<div class=\"alert alert-success\">\nThe first <b>beta<\/b> for the release 11 should appear in the next two days, please help us by testing and reporting bugs.\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Since the release document is lacking here few notes on how it works, it will be updated soon =). Versioning Libav has separate version for each library provided. As usual the major version bump signifies an ABI-incompatible change, a minor version bump marks a specific feature introduction or removal. It is made this way to &hellip; <a href=\"https:\/\/blogs.gentoo.org\/lu_zero\/2014\/08\/16\/libav-release-process\/\" class=\"more-link\">Continue reading <span class=\"screen-reader-text\">Libav Release Process<\/span><\/a><\/p>\n","protected":false},"author":10,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true},"categories":[14],"tags":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p1aGWH-4J","_links":{"self":[{"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/posts\/293"}],"collection":[{"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/users\/10"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/comments?post=293"}],"version-history":[{"count":12,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/posts\/293\/revisions"}],"predecessor-version":[{"id":319,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/posts\/293\/revisions\/319"}],"wp:attachment":[{"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/media?parent=293"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/categories?post=293"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/tags?post=293"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}