On Thursday, 29 November 2012 at 01:29:12 UTC, Jonathan M Davis
wrote:
Since master will almost certainly be the development branch, I
don't see how
that's a problem. The stable branch will be a separate branch,
and whoever is
managing the stable branch will merge stuff from the master
branch into it.
In this case, all bug fixes are mixed with new feature and then
have to be separated afterward and remerged into the stable
branch. This is useless work and it is likely to cause merge
conflict in the stable branch.
Additionnaly, this become to really suck when several new
features are dev at the same time.
Finally, yhis is completely inconsistent with how github work in
the first place.
master make sense as an unstable branch, a release candidate, a
beta or whatever, but certainly not a dev branch.
Granted, major stuff like 64-bit Windows support and UDAs
should probably be
introduced on branches separate from master, and it's still a
problem if
they're not, but it won't affect the stable branch if they're
not.
It will become all bigfixes will be based on code that contains
the new feature.