On Wed, Mar 16, 2011 at 10:55:04AM -0700, Alan Irwin wrote:
> On 2011-03-16 09:38-0000 Andrew Ross wrote:
> > Well one thing that immediately springs to mind is removing the contents of
> > src/pldeprecated.c .
> Hi Andrew:
> Yes, please! We have long given notice in this case so there is no
> question. And adjust doc/docbook/src/api-obsolete.xml accordingly
> while you are at it.
> > There may be other API changes that we have discussed. It would be worth a
> > trawl back through the archives.
> Scanning through headers for some keywords may give some ideas. For
> example, I recently noticed in bindings/c++/plstream.h a whole list of
> functions with the comment
> // Deprecated versions of methods which use PLINT instead of bool
> Is it time for you to remove those?
I'll think about this one.
> Also, searches for "deprecated", "compatability", and "backwards" in
> include/*.h show a number of possibilities for removal.
I've removed a number of macros (e.g. for plcol) which have been marked as
obsolete for some time. Plplot code + examples updated accordingly.
> The other question is whether mention of "deprecated" in the source
> code is sufficient notice to our users. For example, you might want
> to ease them into these removals by making the removals by default,
> but give them an option PL_DEPRECATED to keep all the old cruft just
> for this release with a well-publicized promise to remove that option
> (and all the associated cruft) early in the next release cycle. OTOH,
> you might not want to do that because it extends the period of
> uncertainty, gives more chance for errors to creep in due to that
> extra complication, and those who want to cling to the old ways will
> do so until the last minute in any case.
I've moved a number of such functions into pldeprecated and added a
runtime warning. This file (and associated C++ and fortran bindings) are
wrapped in #ifdef PL_DEPRECATED. You need to explicitly add this to
the cmake command line to get support. This should push users into
updating code. This puts a formal system in place for deprecating
functions and then removing them at a later release.
> I am going to leave all of these decisions (and the implementation and
> timing of that implementation) to you because I trust your judgement
> more than mine on these tricky API matters, and I also still have lots
> of time-consuming stuff left on my PLplot agenda before the release of
> 5.9.8 including extensive testing on the Linux, wine/MinGW/MSYS,
> wine/MinGW, and possibly even wine/Cygwin platforms.
Please test this. User reports useful too. This is quite a change and
a number of the old functions such as plcol still appeared dotted
around the plplot code so I suspect users may be affected too.