<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body >Jeff, I need your personal thoughts on our decision to have a 5.0.1 branch and keep the 5.1 development to be done on the top-of-the-trunk for 5.0.0.
<br>
<br>This will give us the extra-confidence here to move forward.
<br>
<br>I have some queries. Kindly bear with me as I did read the document but was not quick enough to understand it.
<br>
<br>The bug fixes that are being done will be on the 5.0.1 branch. Now, to maintain the same fixes in the 5.1, we also need to make checkins in the 5.0.0 top of the trunk. Is that correct?
<br>
<br>To add to the above combo, we can also integrate the contributions of other features for example the mailing list enhancement from mmbrich (say) to ONLY the top-of-the-trunk.
<br>So, in brief, the 5.0.0 top of the trunk will have the following :-
<br>
<br>the 5.0.0 code
<br>the bug fixes that are going to 5.0.1
<br>the features submitted newly
<br>
<br>The combination of these three is going to be called the 5.1 release.
<br>
<br>Is my understanding correct?
<br>
<br>Richie<br><br><br><br><br>---- Jeff Kowalczyk<jtk@yahoo.com> wrote ---- <br><br><blockquote style='border-left: 2px solid #0000FF; padding: 6px;'><html>
<xbody>
Sergio A. Kessler wrote:<br>> I think this is wrong.<br>> I can understand (not agree) to create a 5.0.1 branch. but why you need<br>> to create a 5.1 branch at all ??? 5.1 development should be done in the<br>> trunk... branching 5.1 the only thing will do is complicate things...<br>> remember KISS (Keep It Simple, Stupid)<br><br>I was going to complement Richie on the right branching naming, etc,<br>procedure...<br><br>The timing of branching is equally important, however, and I think it's<br>too soon.<br><br>We're going to have to decide (and document, and enforce) among the<br>'stable trunk' vs other development models.<br><br>We need to decide where new features get developed, and under what<br>conditions they get merged back to the 'trunk' or branch, as policy<br>decides.<br><br>Everyone discussing this should read:<br><br><a href="http://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html">http://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html</a><br><br>with 'copies are cheap in subversion' in mind. Branches are easy, and the<br>numerous variety of branches (e.g for feature development) should be<br>short-lived (e.g. merge back to trunk or branch, then delete/move branch).<br><br>Maintaining multiple long-lived branches is labor intensive, and might<br>only be undertaken to support long-term maintenance goals, on branches<br>that rarely want to merge changes from 'upstream'.<br><br><br>_______________________________________________<br>Get started with creating presentations online - <a href="http://zohoshow.com?vt">http://zohoshow.com?vt</a> <br>
</xbody>
</html></blockquote></body></html>