[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.
This commit is contained in:
Emmanuele Bassi 2009-07-18 19:40:29 +01:00
parent da37e1e27d
commit f7850b516c
2 changed files with 56 additions and 38 deletions

38
HACKING
View File

@ -87,41 +87,3 @@ brief.
"what" you did and, more importantly, "why" you did it. The "how" is not "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 important, since "git show" will show the patch inlined with the commit
message. 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$

56
RELEASING Normal file
View File

@ -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.