Mauro Talevi wrote:
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.
Hi folks.
Versioning in jbehave and similar projects works like this: the version
numbers are of the form /major.minor.point/.
* A point release is purely bug-fixing or refactoring, with no
changes to any visible APIs.
* A minor release can also introduce new features, so it changes the
API (you can do more stuff, or do different stuff) but respects
compatibility. Any 2.x code will work on a 2.y build if y > x. You
can deprecate functionality in a minor release but it has to still
work.
* A major release is the only time you are allowed to break
compatibility. This usually represents a major changed to the
application, based on new language features (e.g. jmock using
generics in 2.x, or junit using annotations in 4.x). This is where
you would remove deprecated features from the previous major series.
If you remove a deprecated feature, you will by definition break
anyone's code who is relying on that feature (and who wrote their code
before you deprecated it!). So we can't remove any deprecated features
in 1.x, just recommend - both explicitly in docs and implicitly in our
own usage - that people don't use the deprecated stuff.
hth,
Dan
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
