On Sat, Dec 8, 2012 at 7:01 AM, Greg Landrum <greg.land...@gmail.com> wrote:
> My current plan is to keep this branch in sync with the trunk through (at
> least) the Q4 2012 release and then consider moving it onto the trunk and
> creating a v1 API branch in Q1 of next year. I guess I should be able to
> keep the v1 API branch in sync, at least in terms of bug fixes, for another
> 2-3 releases.

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
2. add the v2 methods.
3. release Q4 2012
4. keep the warnings around as much as you feel is fair to give time
for the clients to port code
5. make the real break (remove deprecated methods, change method signature)
6. release a new version with the api break



Gianluca Sforna

http://identi.ca/giallu - http://twitter.com/giallu

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
Rdkit-devel mailing list

Reply via email to