[docs] Move the releasing process to a separate file

The documentation on how to release Clutter should be in a separate
file from the documentation on how to hack on Clutter.

diff --git a/HACKING b/HACKING
index 3b403db..9cfbccd 100644 (file)
--- a/HACKING
+++ b/HACKING
@@ -87,41 +87,3 @@ brief.
    "what" you did and, more importantly, "why" you did it. The "how" is not
    important, since "git show" will show the patch inlined with the commit
    message.
-
-RELEASES
-========
-
-In making a new release;
-
- - Verify your working directory is fresh; i.e., check out a fresh copy
-   or "git reset --hard release_branch && git clean -f".
-
- - Verify versioning in configure.ac, increasing relevant
-   clutter_major_version/clutter_minor_version/clutter_micro_version
-   value. For point releases, bump clutter_micro_version to the next
-   even number.
-
- - If there was no API change (addition, removal), increment
-   clutter_interface_age by two. If there was an API change,
-   set clutter_interface_age to zero. The interface_age is used to
-   keep the soname the same.
-
- - Update NEWS (New feature details, bug #'s), README (Any API changes
-   relevant to developers + version), AUTHORS if relevant.
-
- - Add a Release entry to the ChangeLog noting version.
-
- - Call make distcheck and fix if fails. 
-
- - Upload the tarball.
-
- - Bump clutter_micro_version to the next odd number version.
-
- - Commit.
- 
- - Announce release to waiting world on blog and mailing list.
-
- - Release any dependant add-ons following similar rules to above. 
-   Dont forget to check *.pc file version deps!
-
-$LastChangedDate$

diff --git a/RELEASING b/RELEASING
new file mode 100644 (file)
index 0000000..1c25e7d
--- /dev/null
+++ b/RELEASING
@@ -0,0 +1,56 @@
+RELEASING
+=========
+
+When making a new release;
+
+ - Verify your working directory is clean:
+
+     $ git reset --hard <release_branch>
+     $ git clean -xdf
+
+ - Run:
+
+     $ ./autogen.sh --enable-gtk-doc
+     $ make all
+
+ - Run:
+
+     $ make distcheck
+
+   and fix eventual issues. Commit the fixes.
+
+ - Update NEWS (New feature details, bug #'s), README (Any API changes
+   relevant to developers + version), AUTHORS if relevant.
+
+ - Clean everything again with:
+
+     $ git clean -xdf
+
+ - Verify versioning in configure.ac, increasing relevant
+   clutter_major_version/clutter_minor_version/clutter_micro_version
+   value. For point releases, bump clutter_micro_version to the next
+   even number.
+
+ - If there was no API change (addition, deprecation), increment
+   clutter_interface_age by two. If there was an API change,
+   set clutter_interface_age to zero. The interface_age is used to
+   keep the soname the same across releases.
+
+ - Build everything again, and run distcheck to create the tarball.
+
+ - Tag the release:
+
+     $ git tag -s <version>
+
+ - Bump clutter_micro_version to the next odd number version and commit.
+
+ - Push the branch and then the tag, e.g.:
+
+     $ git push origin master
+     $ git push origin 1.2.4
+
+ - Upload the tarball to clutter-project.org.
+
+ - Announce release to the waiting world on the blog and mailing lists
+
+ - Release any dependant add-ons following similar rules to above.