mutter/doc/RELEASING

64 lines
1.5 KiB
Plaintext
Raw Normal View History

RELEASING
=========
When making a new release;
2010-10-03 11:37:41 -04:00
- Verify that you don't have uncommitted changes; both:
$ git diff HEAD
and:
$ git log master..origin/master
should be empty.
- Clean your work directory:
$ git clean -xdf
2010-10-03 11:37:41 -04:00
This ensures that you don't have stale files lying around.
- Run:
2011-03-14 12:02:13 -04:00
$ ./autogen.sh --enable-gtk-doc --enable-docs
$ make all
2010-10-03 11:37:41 -04:00
$ make check
2010-10-03 11:37:41 -04:00
And verify that the code builds from a clean Git snapshot.
2010-10-03 11:37:41 -04:00
- Update the release documentation:
2010-10-03 11:37:41 -04:00
- NEWS: new feature details, bugs fixed, acknowledgements
- README: dependencies, any behavioural changes relevant to
developers;
2011-03-14 12:02:13 -04:00
then commit the changes.
2010-10-03 11:37:41 -04:00
- Bump clutter_micro_version to the next even number; if this is a stable
release, bump up clutter_interface_version by one as well. Then commit
the changes.
2010-10-03 11:37:41 -04:00
- Run:
2010-10-03 11:37:41 -04:00
$ make release-publish
2010-10-03 11:37:41 -04:00
which will:
2010-10-03 11:37:41 -04:00
- do sanity checks on the build
- distcheck the release
- tag the repository with the version number
- upload the tarball to the remote server (needs SSH account)
2010-10-03 11:37:41 -04:00
- Bump clutter_micro_version to the next odd number; if this is a stable
release, bump up clutter_interface_version by one as well. Then commit
the changes.
- Push the branch and then the tag, e.g.:
$ git push origin master
$ git push origin 1.2.4
2011-03-14 12:02:13 -04:00
- Announce release to the waiting world on the blog and mailing lists. Use
the template printed by `make release-publish`.