Simplify the RELEASING steps based on current release.sh.

Since release.sh creates and pushes a libdrm-$VERSION tag for us,
there's no need to also have the user manually generating a $VERSION
tag as well.

I also dropped the "optional" part of distcheck.  You shouldn't have
pushed master with a version bump that hasn't passed distcheck.

Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>

diff --git a/RELEASING b/RELEASING
index 62c5be9..262ca08 100644 (file)
--- a/RELEASING
+++ b/RELEASING
@@ -9,21 +9,14 @@ However, this is up to whoever is driving the feature in question.
 
 Follow these steps to release a new version of libdrm:
 
 
 Follow these steps to release a new version of libdrm:
 

-  1) Ensure that there are no local, uncommitted/unpushed
-     modifications. You're probably in a good state if both "git diff
-     HEAD" and "git log master..origin/master" give no output.
-
-  2) Bump the version number in configure.ac. We seem to have settled
+  1) Bump the version number in configure.ac. We seem to have settled

      for 2.4.x as the versioning scheme for libdrm, so just bump the
      micro version.
 
      for 2.4.x as the versioning scheme for libdrm, so just bump the
      micro version.
 

-  3) Run autoconf and then re-run ./configure so the build system
+  2) Run autoconf and then re-run ./configure so the build system

      picks up the new version number.
 
      picks up the new version number.
 

-  4) (optional step, release.sh will make distcheck for you, but it can be
-      heart warming to verify that make distcheck passes)
-
-     Verify that the code passes "make distcheck".  Running "make
+  3) Verify that the code passes "make distcheck".  Running "make

      distcheck" should result in no warnings or errors and end with a
      message of the form:
 
      distcheck" should result in no warnings or errors and end with a
      message of the form:
 


@@ -36,20 +29,13 @@ Follow these steps to release a new version of libdrm:
      Make sure that the version number reported by distcheck and in
      the tarball names matches the number you bumped to in configure.ac.
 
      Make sure that the version number reported by distcheck and in
      the tarball names matches the number you bumped to in configure.ac.
 

-  5) Commit the configure.ac change and make an annotated tag for that
-     commit with the version number of the release as the name and a
-     message of "libdrm X.Y.Z".  For example, for the 2.4.16 release
-     the command is:
-
-       git tag -a 2.4.16 -m "libdrm 2.4.16"
-
-  6) Push the commit and tag by saying
+  4) Push the updated master branch with the bumped version number:

 
 

-       git push --tags origin master
+       git push origin master

 
      assuming the remote for the upstream libdrm repo is called origin.
 
 
      assuming the remote for the upstream libdrm repo is called origin.
 

-  7) Use the release.sh script from the xorg/util/modular repo to
+  5) Use the release.sh script from the xorg/util/modular repo to

      upload the tarballs to the freedesktop.org download area and
      create an announce email template.  The script takes one argument:
      the path to the libdrm checkout. So, if a checkout of modular is
      upload the tarballs to the freedesktop.org download area and
      create an announce email template.  The script takes one argument:
      the path to the libdrm checkout. So, if a checkout of modular is