<div class="gmail_quote">On Fri, Aug 17, 2012 at 2:36 PM, Blaise Bourdin <span dir="ltr"><<a href="mailto:bourdin@lsu.edu" target="_blank">bourdin@lsu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Should there be a rule for inclusion in the release tree vs. development? For instance that patches cannot change or delete a public interface and must pass all tests?</blockquote></div><br><div>The minimum requirement must be that they are binary and source-level compatible. That means that no public symbols can be renamed, no public structures can be changed, and no interfaces can be changed. So it basically only allows private changes within the same API and non-conflicting new APIs.</div>
<div><br></div><div>Now implicit in the "pN" naming that these patches are strictly bug fixes. That isn't strictly true, and if we are going to put new (but always "safe") functionality into the release branch, I would prefer to do it as a subminor release. This is the conventional meaning of subminor release, so it's perfectly acceptable in my opinion.</div>