It seems to me deprecation is for when functionality disappears or is radically modified from the perspective of code. This would (ideally) include public APIs with:
- Deleted functionality - Replaced functionality - Functionally relocated to another dependency. - Significantly transformed functionality (methods/api's split apart, combined or otherwise scrambled into new associations where more or less calls are needed or the replacements inherit new baggage, i.e. moving to a fluent style or a builder pattern) A simple in-place rename, or move to another package in the same artifact (packages should not split across artifacts) doesn't seem like it needs deprecation to me. On Tue, Nov 4, 2025 at 10:39 AM Jason Gerlowski <[email protected]> wrote: > Hey all, > > I was hoping to get a few more eyes on a question that came up > recently in a JIRA discussion David and I were having. [1] > > In short: do we require a deprecation prior to moving a user-facing > SolrJ class into a new package on "main"? How about when a SolrJ > class is renamed? > > Technically both *are* breaking changes - in both instances it'll > cause broken compilation of folks' SolrJ code after a version-bump to > (e.g.) Solr 10. A deprecation warning in (e.g.) 9.9 would give users > a chance to switch over to the new name before compilation breaks > entirely, which is a (slightly) better experience. > > But on the other hand, this sort of deprecation clearly isn't as > actionable (and you could argue, "valuable") as one that warns users > that a feature or class is going away altogether. Additionally, it > looks like we haven't worried too much about this in practice. For > example, much (all?) of the "split-package" work that's been done in > the last few years was done without deprecation warnings, and relied > solely on "Upgrade Note" entries instead. [2]. That does seem to > cover much of the gap. > > What do you all think: require deprecation? no deprecation? case-by-case? > > If there's any consensus on this, I can write it up and put it in > dev-docs somewhere? > > Best, > > Jason > > [1] > https://issues.apache.org/jira/browse/SOLR-17562?focusedCommentId=18035152&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-18035152 > [2] https://issues.apache.org/jira/browse/SOLR-16040 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
