<div class="gmail_quote">On 1 March 2012 12:11, Stefan Krah <span dir="ltr"><<a href="mailto:stefan@bytereef.org">stefan@bytereef.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Advantages of separate branches:<br></blockquote><div><br></div><div>Even though I agree on most of your points, I disagree with</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) Neither version is a second class citizen.</blockquote><div><br></div><div>In my experience, this is only true if you have a very strict discipline, or if both branches are used a lot. If there are two branches (say: py2 and py3), and one is used much less (say: py3), that one will always be the second class citizen - the py2 branch, which is used by 'most people' gets more feature requests and bug reports. People will implement the features and bug fixes in the py2 branch, and sometimes forget to port them to the py3 branch, which means the branches start diverging. This divergence makes applying newer changes even more difficult, leading to further divergence.</div>
<div><br></div><div>Another cause for this is the painful merging in most version control systems. I'm guessing you all know the pain of 'svn merge' - and there are a <i>lot </i>of projects still using SVN or even CVS.
</div><div><br></div><div>As such, you need to impose the discipline to always apply changes to both branches. This is a reasonable thing for larger projects, but it is generally harder to implement it for smaller projects, as you're already lucky people are actually contributing.</div>
<div><br></div><div>Best,</div><div>Merlijn</div></div>