Elizabeth Keogh wrote:
Hi all,
You know the ethics of release better than I do.
Is it OK to deprecate classes, if I don't actually remove them prior to
2.0?
Deprecated classes don't need to wait necessarily until major release to be removed, ie can be
removed at release 1.n if it deprecated at release 1.m with m < n.
Typically, the usual convention people adopt is to keep the deprecated classes until the next major
release, but often because it's less hassle and safer, as it does not assume users have removed
deprecated usages.
I guess the call needs to be made on how essentially they are bound to the API contract of 1.0
release.
I would like to move all the Matchers into an org.jbehave.core.matchers
package as Michael suggested, but I want to maintain backwards
compatibility. I also need to do this if I want to move CustomMatcher
into its own class but still maintain compatibility with
UsingMatchers.CustomMatcher .
+1
PS: UsingMatchers is going to be very much smaller too.
PPS: UsingMatchers will still be non-static, but all submatchers will be
static. This should allow 1.5ers to statically import matchers, while
also allowing people to eg: override eq(...) to include Hibernate
deproxifying.
cool!
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
