Yes, but in this case, I recall the "stable" release was 0.2.0. Now,
that's not a "true" stable release according to the new QA rules
(because you can't have a "stable" 0.x.x package). Which is why, in
HTML_CSS (which is in the same pickle, btw, due to historical factors),
I'm going to roll out a completely new API for 1.x, but... I'm trying to
"grandfather" the old methods in wherever possible (as Helgi suggested
in your case). Yeah, noting that it's deprecated in the apidocs,
throwing a notice (that can be suppressed for the package by defining a
constant) and not including it in the end-user documentation (but
maintaining it for the life of 1.x) is probably your best bet.
This is exactly what I plan on doing. The problem is that the RFC doesn't mention anything about grandfathering in older packages that went stable at less than 1.0.0.
--Joe
Hope this helps,
Klaus