mutter/HACKING
Emmanuele Bassi 9d5e9aaa9a 2008-01-30 Emmanuele Bassi <ebassi@openedhand.com>
* HACKING: Expand the "document API" point, and the release
	process.

	* README: Update the release notes regarding the scale behaviour,
	now that the gravity has been removed.
2008-01-30 13:05:10 +00:00

62 lines
1.7 KiB
Plaintext

GENERAL
=======
General notes and rules on clutter core hacking;
- GNU style indentation, please wrap at 80 chars.
- All non static public API funcs should be documented in the source files
via gtk-doc. Structures, enumerations and macros should be documented in
the header files.
- All non-trivial static and private API should be documented, especially
the eventual lifetime handling of the arguments/return values or locking
of mutexes.
- All public functions with float parameters should also provide a fixed
point version. Fixed point should be used internally.
- Properties should always be float (never fixed).
- API funcs should always check their arguments with g_return_*().
- Really try to avoid if possible additions to clutter-private.h
- Don't add direct GL calls but wrap with cogl (also adding GL ES Version)
- Use CLUTTER_NOTE() macro for debug statements.
- New features should also include an exhaustive test in tests/
RELEASES
========
In making a new release;
- Check out a fresh copy from SVN.
- verify versioning in configure.ac, increasing relevant
clutter_major_version/clutter_minor_version/clutter_micro_version
value.
- 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 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$