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

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 tabs for indentation. Set the tabwidth of your editor to 4.

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)

8. Use "auto" or range-based for loops to make iterations on container classes more readable

9. The singleton pattern is quite over-used in Hydrogen. If you're adding new classes / servers, 
   please take a moment to consider if it really has to be a singleton.

10. Maximum line length is 120 chars

11. Hydrogen is a cross platform application, which needs to be build on a great range of architectures and operating systems.
    Use only C++11 features and do not use any platform specific compiler extensions without the need to do so.

COMMITTING 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


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. Run `src/gui/src/about_dialog_contributor_list_update.sh
     GIT_TAG_OF_LAST_RELEASE HEAD` to update the list of recent
     contributors.

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

  8. Build binary packages in Appveyor for Windows and macOS:

     - fast-forward merge (or force-push if necessary) releases/XXX to
       releases/XXX-artifacts, and ensure that the head commit is the
       one pointed to by the release tag above.
     - appveyor will build and keep the binary packages as artifacts.

  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. Build a github release, incorporating binary packages, source package, tag and release announcement

  11. Make release announcements on
      - hydrogen-users@lists.sourceforge.net
      - hydrogen-music.org

  12. Update Homebrew Hydrogen cask:
      - PR against https://github.com/Homebrew/homebrew-cask/blob/master/Casks/hydrogen.rb
