On 29 November 2012 03:48, deadalnix <deadal...@gmail.com> wrote: > 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. >
