Garrett D'Amore wrote: >> I disagree. All evidence points to this API being a Public API in the >> community already, there's no reason for it to be private here, and then >> complicate things further with contracts. My only suggestion would be >> to find a way to make the documentation more accessible (perhaps by >> creating a stub libgs man page that points to the API.htm file) to >> reflect the stability level of the API. >> > > But we already have precedent for this with OpenSSL. A private API > which requires Contracts, even though its used by many many open source > projects.
Not private but Contracted External (now Contracted Volatile) and documented. Yes there is a stub openssl man page but that is because historically we had confusing about where man pages should be when binaries/libraries were in /usr/sfw. > The reason for this is that OpenSSL upgrades have a track > record of breaking interfaces. The reason it was done for OpenSSL was because it was known not to have a stable API or ABI at the time. That has changed over time and the massive number of ARC contracts (more than any other case in history and I'm sure there as some missing) has become a total paperwork burned with no pay off. That is going to change very very soon as OpenSSL is quickly approaching a 1.0.0 release (it is currently in Beta 2). At the point it reaches 1.0.0 we plan to no longer use contracts. So given the above please don't use OpenSSL as a precedent setting case - unless it is to demonstrate that for unmodified upstream community FOSS the contract system is unworkable in some cases. -- Darren J Moffat