<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 19 November 2015 at 09:43, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
</span>So we have three models. The release:independent model is for projects<br>
that don't follow the common development cycle, and therefore won't make<br>
a "liberty" release. The release:cycle-with-milestones model is the<br>
traditional "one release at the end of the cycle" model, and the<br>
release:cycle-with-intermediary model is an hybrid where you follow the<br>
development cycle (and make an end-of-cycle release) but can still make<br>
intermediary, featureful releases as necessary.<br></blockquote><div><br></div><div>Hmm, then it seems to me that OpenStack-Ansible should be tagged 'release:cycle-with-intermediary' instead of 'release:independent' - is that correct?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Looking at your specific case, it appears you could adopt the<br>
release:cycle-with-intermediary model, since you want to maintain a<br>
branch mapped to a given release. The main issue is your (a) point,<br>
especially the "much later" point. Liberty is in the past now, so making<br>
"liberty" releases now that we are deep in the Mitaka cycle is a bit<br>
weird.<br></blockquote><div><br></div><div>The deployment projects, and probably packaging projects too, are faced with the same issue. There's no guarantee that their x release will be done on the same day as the OpenStack services release their x branches as the deployment projects still need some time to verify stability and functionality once the services are finalised. While it could be easily said that we simply create the branch, then backport any fixes, this is not necessarily ideal as it creates an additional review burden and doesn't really match how the stable branches are meant to operate according to the policy.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Maybe we need a new model to care for such downstream projects when they<br>
can't release in relative sync with the projects they track.<br></blockquote><div><br></div><div>Perhaps. Or perhaps the rules can be relaxed for a specific profile of projects (non core?).</div></div>
</div></div>