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]
