Content-type: multipart/related; boundary="Boundary_(ID_miLWUIdT+NkGN39FVcnAaQ)"; type="text/html" --Boundary_(ID_miLWUIdT+NkGN39FVcnAaQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable

On Dec 06, 2012, at 11:52 AM, Christopher Sean Morrison <brlca=> wrote:

I, again, forgot about that doc. I think I once befo= re suggested it,
but it would sure help me, and maybe others, to have = that doc moved to
the top of the brlcad tree and renamed DEPRECATION o= r some other
Good idea.  Will do, maybe as CHANGES.

This has been done.
I reviewed a few dozen other projects and CHANGES was indee= d a common method across several projects that had similar intentions to a= nnounce deprecation, API, and tool changes affecting developers (separate = from announcing user-visible changes).  For now, it's the same conten= t, but it might be worthwhile to reorganize the file.  Suggestions we= lcome!

It doesn't yet address library version com= patibility as nearly every release (even patch) is technically incompatibl= e.  That is intentional, however, to encourage rapid API evolution. &= nbsp;We have a lot of issues that need to be fixed.  At least until w= e get a better handle on most of the core libraries (libbu, libbn, libnurb= s, librt, libwdb, and libged), the roadmap entails:


= --Boundary_(ID_miLWUIdT+NkGN39FVcnAaQ)--