Updated usb related issues (markdown)
[librecmc/open-ath9k-htc-firmware.wiki.git] / BranchPolicy.md
1 # Branching? Why would we even support branching?
2
3 Why would there even be branching? Surely development can just happen in master and everyone can just upgrade!
4
5 So, to be clear:
6
7 * Active development is going to happen on master - not branches;
8 * But over time the firmware API is going to change, requiring ath9k_htc driver changes;
9 * Branches exist purely so developers and operating system maintainers who wish to use a given release can use said given release; and
10 * If external companies wish to ship a given version of firmware (and thus API) but include basic bugfixes to users, they may wish to backport bug fixes and improvements to a release branch.
11
12 Thus - a branch will be tagged for each firmware release. If developers, companies, OS distributions, etc wish to maintain a given version of ath9k_htc and firmware on their project then they're very welcome to - but they'll have to put in the effort to backport fixes/improvements without braking the firmware API.
13
14 The branch exists so that these developers/companies/distributions can participate in a centralised way. Hopefully we don't end up with the situation where each OS vendor creates a fork of the firmware and maintains it themselves - hopefully they will push patches into the release branch so everyone can benefit.
15
16 The branch rules:
17
18 * The version number won't change in a branch (although it may be time a revision ID was included in the version information pushed back up to the host);
19 * The firmware API and behaviour must not change along a branch;
20 * A branch update must not require an ath9k_htc driver update to function. It may go hand-in-hand with some vendor patches to ath9k_htc to fix some particular issue, but the firmware must still function on the latest version of ath9k_htc which is paired with the branch version;
21 * Any fixes to a branch must first be applied and debugged in master before backported.
22 * .. ie, features/fixes must not go into a branch first.
23
24 If not - the branches themselves will just stay what they are - indicators of when things were released.