<div dir="ltr">On Thu, Apr 16, 2015 at 2:10 PM, Richard Raseley <span dir="ltr"><<a href="mailto:richard@raseley.com" target="_blank">richard@raseley.com</a>></span> wrote:<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am certainly sympathetic to your situation - having the world change beneath your feet is never a good place to be. =]<br>
<br>
It does seem, however, that there is a disconnect between your expectations (as I understand them) of what the 'master' branch represents, and what it has traditionally represented - the 'bleeding edge'<br>
<br>
Master is volatile - it is expected to be volatile. As the code progresses between releases it is expected that things can (and will) break.<br>
<br>
The solution, in my mind, is not to redefine what it means to be master, but rather to be more aggressive about back-porting changes to stable branches.<br></blockquote><div><br></div><div>I agree that in theory, it should work like you suggest.  However, as they say: “In theory, theory and practice are the same. In practice, they are not.”  In practice, we're not as good at back porting things as everyone would like.  I'll be as happy as anyone else to see this continue to improve, but it's a given that it'll never be perfect.   In practice, if you wanted to upgrade to Juno, we needed to be on master, because even in January it wasn't ready for the sort of configurations we were running, and we're not doing anything overly weird.</div><div><br></div><div>Additionally, as Matt said, those of us that are upgrading production environments are the ones contributing back fixes that have to land in master first, and then we have to wait for an additional back port.  We've several times found bugs that break production deployments and had to carry local patches, but we try to contribute everything back as quickly as possible.  We'll continue to do this regardless, but we certainly have less incentive to do it quickly if we're going to have to carry it locally for the length of time a back port takes.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am very much in favor of discussions that include your proposed solution above (i.e. 'current-1' support), as long as it is identified as a transitional step; I do pretty strongly believe that the right long-term model is to treat master as the 'bleeding edge' and to only pin yourself to stable releases.<br></blockquote><div><br></div><div>We're not following master blindly.  We import most modules once a week, run them through CI before merging them and QA them before deploying.  Doing that is *dramatically* easier than trying to update to a new, massively different puppet module twice a year.  If there is no overlapping compatibility between <current release> and <previous release> then upgrading requires making massive changes to infrastructure while making massive changes to the automation that drives it.  </div><div><br></div></div></div></div>