<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 20, 2014 at 4:14 AM, Eric Fiselier <span dir="ltr"><<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't really like allowing users to pick and choose which ABI<br>
changes to adopt. I personally don't see the use case for picking a<br>
subset of ABI changes to adopt. If you can adopt one ABI change,<br>
then why can't you adopt them all? Furthermore, as time goes on and<br>
more ABI changes are commited this could lead to quite a mess.<br>
<br>
I also don't like having a stable version and an unstable version of<br>
the ABI. I'm afraid that by only introducing ABI changes into the<br>
"unstable ABI configuration" they will never be adopted.<br>
<br>
Instead I think we should version the ABI and introduce a series of<br>
stable ABI's under different versions. This allows us some sort of<br>
forward momentum and fewer configurations that need maintaining and<br>
testing.<br>
When a consumer can tolerate introducing an ABI break they can move to<br>
the most recent ABI version. After a given amount of time ABI versions<br>
would be deprecated.<br>
The only ABI versions that would be maintained indefinitely would be<br>
the current one.<br></blockquote><div><br></div><div>This idea of ABI "version" paradigms well with real world packages. At some point we'll in theory have many libc++ packaged and released. If at the same time of the ABI breakage the libc++.so.${N} is incremented we have some tangible way to relay that information to potential end users.</div><div><br></div><div>I'm personally against the #if hell which could result in multiple universes (I'd rather put a "stable" piece of code in a maintenance branch, but that's must my not-so-humble opinion.) It's like saying that the IR should be stable and never change... This is more user facing and gets more hand waiving, but at the end of the day it's the same sort of problem.</div><div><br></div><div>Every time a set of ABI breaking changes happen.. bump the lib version, cut a branch before the changes and move on with life... what's so wrong about this? Changes can be ported forward/backward to the branch as the owners want. Keep code complexity down..</div><div><br></div><div>Further - how do you QA libc++ when there's basically "2" correct ways to build it? Have the buildbots build it twice and report both results?</div><div><br></div><div>For anyone who wants or demands stability.. I'd love to hear why a branch won't work..</div><div><br></div><div><br></div></div></div></div>