> I was wrong about a few things on how it's actually handled in QubesOS.
* currently Whonix11 branch contains latest commits
* master contains status of latest Whonix stable (Whonix 10 at time of writing)
all [Whonix](https://github.com/Whonix) packages, such as [whonix-gw-firewall](https://github.com/Whonix/whonix-gw-firewall) etc.
* master contains status of latest developments
* Whonix10 maintenance branch
* Whonix11 maintenance branch (since soon to be released)
most (all?) [Qubes](https://github.com/QubesOS) packages such as [qubes-builder-debian](https://github.com/QubesOS/qubes-builder-debian), [qubes-core-agent-linux](https://github.com/QubesOS/qubes-core-agent-linux):
* master contains status of latest developments, looks like
* branches for maintenance (and history perhaps) such as release2, looks like
To sync things... Adapt the same style to qubes-whonix package. I.e. let master reflect latest commits.
* No need to explain to future contributors "don't base on master, that's just maintenance, base on Whonix11 branch, is latest", followed by replacing that with Whonix12 in future.
* Most common way to handle use of master branch?
* Activity on github looks better. Github defaults to master. People see latest commit was not so long ago and perhaps look into those. Better than being swamped when it's merged into master at release time.
* One step less (choosing Whonix11 branch) when creating github pull requests.
* Most pull requests are based on latest (ideally: master) rather than specific versions.