Comment 9 for bug 1708048

I don't disagree, Jason. I think that does put stretch support outside the Evergreen 3.0 window, though, and into 3.1 territory.

It will mean changing the opensrf.xml file for C-based app implementations in Evergreen, and will almost certainly break binary compatibility at the OpenSRF level. I'm a'feared of doing all that this late in the release cycle. My hope was to get stretch support now, without needing an OpenSRF version bump...

Should we target this at Evergreen 3.next and (the hypothetical) OpenSRF 2.next?