On Dec 9, 2012, at 8:06 PM, Gianluca Sforna wrote:
> I believe a commonly accepted approach to this kind of issues is something
> like:
>
> 1. add warnings about the deprecated or changed methods, but keep the
> current behavior so code do not break, but becomes verbose when called
...
That progressive set of changes is very context dependent.
Some projects have the above policy, but not all. Even within a
project, some parts of a package can break backwards compatibility
while others do not.
For an obvious example, if the API is broken, then there's no need
to go through this very careful transition plan. No one can be using
it so just fix the API.
Similarly, even if the API is working (as this one is), it may be
that no one is using it. Or it may be that one person is using it
(like I am) but the migration path from the old API to the new one
is only a few lines of code, while the internal changes to support
both APIs is very complicated.
I believe Greg's proposal is an example of the latter. That is,
I suspect that:
1) few people currently use the API,
2) of those, most can trivially port to the new API, and
3) supporting both the old and new APIs is complicated
I have no problems with doing a flag-day change for the Q1 or Q2 release.
Andrew
da...@dalkescientific.com
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel
