[gnome-utils] [docs] Document the release process



commit f9677a66f088db67b590080e85cd934e226ffd92
Author: Emmanuele Bassi <ebassi gnome org>
Date:   Tue May 5 02:15:40 2009 +0100

    [docs] Document the release process
    
    Currently, we follow the GNOME guidelines, but a document detailing
    how to make a release should still be available.
---
 README.releasing |   90 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 90 insertions(+), 0 deletions(-)

diff --git a/README.releasing b/README.releasing
new file mode 100644
index 0000000..184c6f7
--- /dev/null
+++ b/README.releasing
@@ -0,0 +1,90 @@
+The GNOME Utilities project follows some rules on how to make a release:
+
+  - If this is your first release, please go to:
+
+      http://live.gnome.org/MaintainersCorner/Releasing
+
+    and read up. The gnome-utils project follows a slightly different
+    process but you should familiarise yourself with the official
+    guidelines anyway.
+
+  - Clean up the repository using:
+
+        git clean -xdf
+
+    this will remove any non-tracked file from the repository; make sure
+    you don't have new files you haven't committed first!
+
+  - Regenerate the build environment using:
+
+        ./autogen.sh --enable-gtk-doc
+
+    the '--enable-gtk-doc' bit is mandatory as long as we ship with
+    the libgdict API reference.
+
+  - Make all
+
+  - Run:
+
+      make distcheck
+
+    and verify that a tarball is created and distcheck passes. If the
+    distcheck does not pass fix any issue you find.
+
+  - Edit the NEWS file for the new release. The header for the release
+    section is:
+
+====================================================================
+GNOME Utilities X.YY.ZZ (DAY MONTH YEAR) - "CODENAME"
+
+    Usually the code name is the title of a song. After the header goes
+    the shortlog generated by using:
+
+        git shortlog (X.YY.ZZ - 1)..
+
+    where (X.YY.ZZ - 1) is the tag for the previous release, e.g.:
+
+        git shortlog 2.27.1..
+
+    This will generate the list of commits, broken down by author
+    name, since the last release.
+
+  - Edit the README file to change the version and code name for the
+    release.
+
+  - Commit the changes using:
+
+      git commit -m "[release] X.YY.ZZ" NEWS README
+
+  - Run:
+
+      make distcheck
+
+    again. This will generate a ChangeLog up to the release commit.
+
+  - When distcheck ends, move the tarball in another directory and
+    double check the last changes. Then copy it to gnome.org for
+    the release process.
+
+  - Tag the release using:
+
+      git tag -s -m "Release X.YY.ZZ" X.YY.ZZ
+
+    Do NOT tag using something like "GNOME_UTILS_X_YY_ZZ". Tags like
+    that will be ignored and a new "X.YY.ZZ" tag will be used instead.
+
+  - Bump up the version number in configure.ac and commit.
+
+  - Push the newly created tag and then push the branch, e.g.:
+
+      git push origin X.YY.ZZ
+      git push origin master
+
+  - SSH into gnome.org and call install-module on the tarball you
+    previously uploaded.
+
+  - Send the release announcement to gnome-utils-list gnome org and
+    CC: gnome-announce-list gnome org 
+
+Any change to the release process MUST be discussed with the rest of
+the maintainers.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]