<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 31, 2014 at 4:35 AM, Moritz Lennert <span dir="ltr"><<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 29/03/14 21:56, Vaclav Petras wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
Inspired by what code sprint people were saying, I put together my<br>
proposal. It counts with release once a year and a half year bugfixing<br>
(feature freeze) period before the release. I expect comments and<br>
criticism and I would be glad to compare this proposal with some other<br>
proposal.<br>
<br>
Vaclav<br>
<br>
<br>
Releasing and branch management should follow these steps:<br>
<br></div>
 1. have trunk<br>
 2. fork release branch , e.g. release_7_1<br>
 3. only bugfixes to release branch, new features (additions,<div class=""><br>
    refactoring, documentation) only to trunk<br></div>
 4. release new version based on release branch, , e.g. 7.1.0<br>
 5. only critical bugfixes go to release branch, release patched version<div class=""><br>
    if needed, e.g. 7.1.1, .7.1.2<br></div>
 6. fork a new release branch (e.g. release_7_2), set old release branch<div class=""><br>
    to readonly and continue with point 3.<br>
<br>
It seems that release should be done every year. A new release branch<br>
should be forked half a year before planned release.<br>
</div></blockquote>
<br>
I find that 6 months is a fairly long period to maintain a bugfix-only branch. I would rather propose to either branch later, or to allow more than just bugfixes into the release branch for 4-5 months before going into bugfix-only phase for the last month or two. During the first period new features can be ported to the release branch once they have had some testing in trunk.<span class="HOEnZb"><font color="#888888"><br>


<br></font></span></blockquote><div><br></div><div>Moritz, I believe that these are two different things.</div><div><br></div><div>First, the lengths of time periods. First question is how often we want to release MAJOR.MINOR version. Once a year looks good for me but I have no special reasons for this. The length of period between fork and release can be probably anything from 1 month to 6 months. The length of period after release to next release should be the rest so from 6 month to 11.</div>

<div><br></div><div>Second, committing features to both branches is what is taking the time from us and creating uncertainty about what is where and what are the branches for. I think that this is crucial point and the lengths of time periods above should be decided based on this, not the other way around.</div>

<div><br></div><div>Vaclav</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
Moritz<br>
</font></span></blockquote></div><br></div></div>