DEVELOPERS

DEVELOPER INFO
==============

MAKING A RELEASE
----------------

Transitioning the code to remove some of the development hooks in
order to make a release has several, easy-to-forget steps.  They are:

  1. Set the version
     a. Configure the correct version in CMakeLists.txt

     b. Update linux/debian/changelog

     c. Check if nothing has changed and update version and date in
        linux/hydrogen.1 

  2. Remove the 'developer warning': in data/hydrogen.default.conf
     change hydrogen_preferences/showDevelWarning to "false".

  3. Commit your changes.

  4. Make a tarball of the release (gzipped).  Use gzip instead of
     bzip2 for the folks on Windows.  Tarballs should be named:
                   
                   +--- Release version
                   |
                   |    +--- Extra release version info
                 __|__ _|_
        hydrogen-0.9.4-rc2.tar.gz
	
     Example: 'tar -pczf hydrogen-0.9.5.tar.gz hydrogen-0.9.5' 

  5. If this is an RC release, the following steps are optional.

  6. In a clean directory, test build the tarball in as many ways as
     you can.  Call your friends.  Have a party.  Be sure to build
     packages on as many systems as possible.  Be sure to install
     and uninstall them, too.

  7. Go ahead and build binary packages.  Follow the naming convention
     for the platform that you're building for.

       Linux:    hydrogen_0.9.4rc2_distro_arch.pkg
                 distro:  the GNU/Linux distro (e.g. 'lenny' for Debian)
                 arch:    the processor it's built for (e.g. i686)
                 pkg:     the package management system (deb, rpm)
       OS X:     hydrogen_0.9.4rc2_arch.dmg
                 (arch is optional if the binary will work on both.)
       Windows:  hydrogen_0.9.4rc2.exe

  8. If the release passes these "internal" tests, tag the
     release.  Remember, after tagging the release you may not
     commit changes to the tag.

     git tag -a 0.9.4 -m "Tagging 0.9.4"

  9. If this is a major release (e.g. 0.9.4), then make a branch for
     maintenance patches for your release.  If this is a maintenance
     release (e.g. 0.9.4.1) then skip this step.

     git branch 0.9.4
     git push origin 0.9.4

  10. Make announcements.

CODING CONVENTIONS
------------------

We are aware of the fact that not the whole codebase uses the same conventions at the moment.
But we would like to establish the following rules, based on best practices. The numbering has no deeper meaning,
its just for referencing the items.

1. Use the 'linux' indention for source code.  (i.e. Tabs)

2. Allow extra space within
parentheses, like this:

     while( !done ) {
             foo();
     }

3. Please don't refactor our code because you just don't like its style or you think that things could be
just a little bit better if reformat the code to fit your style.

4. Use curly braces for all if statements, even one liners. We don't need to minimize the lines of code :)

Good: if( a ){
        doB();
      }

Error prone: if( a ) doB();

     if( a )
        doB();

5. Method names follow the camel case naming scheme, starting with a lowercase letter.

  Example: void doB( int * myArgument );

6. Use speaking and self-explaining names for your variables (exception: loop-variables). We don't need to use short
likes i,n,aux etc...

7. Prepend pointer types with a "p" (for example: pMySample), floats with an "f", integer types with an "n" and members of a class with an "m_" (for example: m_pEngine)


COMMITING YOUR CODE
-------------------

The easiest way to participate in the development of hydrogen is to create a fork at github and create a pull request
from your changes.

Please take the following things into account:

1. If you want to send us a bug fix, please include only the commits which are part of the bug fix. Do *not* mix in new
features or refactor code.

2. You can reference the github issue number in your pull request if you want to fix a bug which is already known in our bugtracker