<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 15, 2016 at 3:16 PM, Pranith Kumar Karampuri <span dir="ltr">&lt;<a href="mailto:pkarampu@redhat.com" target="_blank">pkarampu@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">hi,<br>
        Yesterday Vijay, Niels and I discussed(#gluster-dev) that there has been a tension/conflict between keeping a release stable vs maturing new features where users have been giving feedback.<br>
At the moment if the feature misses a release, for us to get feedback from users it generally takes 7-8 months because it needs to get into next release. So we want to shorten it by following shorter minor release cycles (3months) with some releases termed as long term support(LTS) like we have in Ubuntu world(At least that is where I first heard it). So the proposal is to have 3.8 as long-term support release, 3.9 to be released in September which is not a long-term support release. As soon as 4.0 gets released 3.9 based releases will stop as all those features will move to 4.0. branch. This will make sure that small features won&#39;t be backported to already released branches. Also we can point enthusiastic users to try the new features out in the next release, which is not too far off.<br></blockquote><div><br></div><div>Does this mean we will have to maintain only two releases at a time? One LTS and one non-LTS.</div><div>What will happen to 3.6 and 3.7?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
       From a user&#39;s perspective people who are not looking for any new features should stay on long-term-support branch based releases. Where as people who are interested in a new feature can start their testing with release where the feature is available whether it is going to be long-term-support or not and give us feedback, if they like the stability they can even put that in production. Once the feature is in a LTS branch they should stick to LTS branches from then on.<br>
<br>
        Please feel free to let us know what you guys think about this. Main problem we need to solve is to prevent new features to land in the middle of stable release cycles. At the same time not have longer wait times for users to give us feedback.<br>
<br>
Pranith<br>
_______________________________________________<br>
maintainers mailing list<br>
<a href="mailto:maintainers@gluster.org" target="_blank">maintainers@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/maintainers" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/maintainers</a><br>
</blockquote></div><br></div></div>