forked from hydrogen-music/hydrogen
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathDEVELOPERS
141 lines (93 loc) · 4.86 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
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
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++17 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 ChangeLog
c. Check if nothing has changed and update version and date in
linux/hydrogen.1
d. Update the TARGET_VERSION variable in .appveyor.yml
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. Add a corresponding version tag in the documentation and update
the submodule.
4. Commit your changes.
5. 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'
6. If this is an RC release, the following steps are optional.
7. 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.
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. 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.
10. 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
11. Build a github release, incorporating binary packages, source
package, tag and release announcement.
12. Upload the release to SourceForge and make it the default download
for all supported platforms.
13. Make release announcements on
- hydrogen-music.org
14. Update Homebrew Hydrogen cask:
- PR against https://github.com/Homebrew/homebrew-cask/blob/master/Casks/hydrogen.rb