forked from hydrogen-music/hydrogen
-
Notifications
You must be signed in to change notification settings - Fork 0
/
DEVELOPERS
115 lines (77 loc) · 3.84 KB
/
DEVELOPERS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
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 verion in CMakeLists.txt
b. Update linux/debian/changelog
2. Remove the 'developer warning': in data/hydrogen.default.conf
change hydrogen_preferences/showDevelWarning to "false".
3. Commit your changes to trunk.
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