Bump release to 2.0.0 and document release schedule & versioning

This bumps the release number of 2.0.0, to reflect the switch to
a new time based release versioning scheme. The downloads page
is updated to describe our policies for release schedules and
release version numbering

The stable release docs are changed to reflect the fact that
the stable version numbers are now just 3 digits long instead
of 4.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

diff --git a/configure.ac b/configure.ac
index 827d9db7966077e5e4eb972388944cf0cbb7d9c1..011414935c4775d3f2c6734ec4531e79079aa4b6 100644 (file)
--- a/configure.ac
+++ b/configure.ac
@@ -16,7 +16,7 @@ dnl You should have received a copy of the GNU Lesser General Public
 dnl License along with this library.  If not, see
 dnl <http://www.gnu.org/licenses/>.
 
-AC_INIT([libvirt], [1.3.6], [libvir-list@redhat.com], [], [http://libvirt.org])
+AC_INIT([libvirt], [2.0.0], [libvir-list@redhat.com], [], [http://libvirt.org])
 AC_CONFIG_SRCDIR([src/libvirt.c])
 AC_CONFIG_AUX_DIR([build-aux])
 AC_CONFIG_HEADERS([config.h])

diff --git a/docs/downloads.html.in b/docs/downloads.html.in
index 13a6db1a1398dd6c825faf652e37e1863b075775..32cc2ec2aa1f30ca758b16abc3dc60faf9760b91 100644 (file)
--- a/docs/downloads.html.in
+++ b/docs/downloads.html.in
@@ -32,20 +32,71 @@
       <li><a href="http://libvirt.org/sources/libvirt-git-snapshot.tar.gz">libvirt.org HTTP server</a></li>
     </ul>
 
+    <h2><a name="schedule">Primary release schedule</a></h2>
+
+    <p>
+      Libvirt follows a time based plan, with releases made once a month
+      on the 1st of each month give or take a few days. The only exception
+      is at the start of the year where there are two 6 weeks gaps, giving
+      a total of 11 releases a year. Expect to see releases on approx:
+    </p>
+
+    <ul>
+      <li>Jan 15th</li>
+      <li>Mar 1st</li>
+      <li>Apr 1st</li>
+      <li>May 1st</li>
+      <li>Jun 1st</li>
+      <li>Jul 1st</li>
+      <li>Aug 1st</li>
+      <li>Sep 1st</li>
+      <li>Oct 1st</li>
+      <li>Nov 1st</li>
+      <li>Dec 1st</li>
+    </ul>
+
+    <h2><a name="numbering">Release numbering</a></h2>
+
+    <p>
+      Since libvirt 2.0.0, a time based version numbering rule
+      is applied. As such, the changes in version number have
+      do not have any implications wrt the scope of features
+      or bugfixes included, the stability of the code, or the
+      API / ABI compatibility (libvirt API / ABI is guaranteed
+      stable forever). The rules applied for changing the libvirt
+      version number are:
+    </p>
+
+    <ul>
+      <li><code>major</code> - incremented by 1 for the first release of the year (the Jan 15th release)</li>
+      <li><code>minor</code> - incremented by 1 for each monthly release from git master</li>
+      <li><code>micro</code> - always 0 for releases from git master, incremented by 1 for each stable maintenance release</li>
+    </ul>
+
+    <p>
+      Prior to to 2.0.0 the major/minor numbers were incremented
+      fairly arbitrarily, and maintenance releases appended a
+      fourth digit.
+    </p>
+
     <h2><a name="maintenance">Maintenance releases</a></h2>
     <p>
       In the git repository are several stable maintenance branches,
       matching the
-      pattern <code>v<i>major</i>.<i>minor</i>.<i>micro</i>-maint</code>;
+      pattern <code>v<i>major</i>.<i>minor</i>-maint</code>;
       these branches are forked off the corresponding
-      <code>v<i>major</i>.<i>minor</i>.<i>micro</i></code> formal
+      <code>v<i>major</i>.<i>minor</i>.0</code> formal
       release, and may have further releases of the
-      form <code>v<i>major</i>.<i>minor</i>.<i>micro</i>.<i>rel</i></code>.
+      form <code>v<i>major</i>.<i>minor</i>.<i>micro</i></code>.
       These maintenance branches should only contain bug fixes, and no
       new features, backported from the master branch, and are
       supported as long as at least one downstream distribution
       expresses interest in a given branch.  These maintenance
-      branches are considered during CVE analysis.
+      branches are considered during CVE analysis. In contrast
+      to the primary releases which are made once a month, there
+      is no formal schedule for the maintenance releases, which
+      are made whenever there is a need to make available key
+      bugfixes to downstream consumers.
     </p>
 
     <p>

diff --git a/src/libvirt_lxc.syms b/src/libvirt_lxc.syms
index 56c24c00f771b9e475270ce3c6542788dd6ae268..9b418eeae94bf42bb1b90d94a97598f3b0d9bb0c 100644 (file)
--- a/src/libvirt_lxc.syms
+++ b/src/libvirt_lxc.syms
@@ -21,7 +21,7 @@ LIBVIRT_LXC_1.0.4 {
         virDomainLxcEnterSecurityLabel;
 } LIBVIRT_LXC_1.0.2;
 
-LIBVIRT_LXC_1.3.6 {
+LIBVIRT_LXC_2.0.0 {
     global:
         virDomainLxcEnterCGroup;
 } LIBVIRT_LXC_1.0.4;