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.

Why don't you document precisely what branches you think should exist, and the working merge/rebase policies.

I'm actually very curious to know.

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.