> Is that what you mean to suggest in the case of 1:1 method renames with no > functionality change? Such a change does break compilation, but it's a > trivial fix (if properly documented). I think it's understood through this > entire conversation that back compat breaks are a "major version only" > prospect, but the question is where to draw the line on deprecation vs > simply changing it at the major version boundary.
It is more work to provide a rename or package move if you also need to produce shims for the old behavior to work. And in SolrJ for v10 we even re-use a previous class name for a differenet purpose, so for such a change to work with deprecation we'd need to place the new impl in a different package. No wonder some frameworks include version in the package name. So in 90% of the cases, yes, we should first implement and release the new and better API, then deprecate the old and finally remove in next major. For Tika I first introduced the new "tikaserver" backend before deprecating the "local" backend. But our project have several examples of us deprecating features without a replacement (DIH, CDCR, Autoscaling). Sometimes that is the only option if we discourage use of the old impl for any production use. Jan --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
