Hi Jan, On 5.11.2025 01:44, Jan Høydahl wrote: > 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.
Including a version number in the package name is typically done when a library is used as a deeply nested transitive dependency, and consumers cannot migrate to the new version all at once. In such cases, you either include both the new classes and shims for the old ones in the same Maven module (case 5 in JLBP-6 [1]), or you change the Maven coordinates entirely (case 4). Projects like Commons, HttpClient, and Log4j follow this approach, but I don’t think it’s necessary for SolrJ. For instance, the Elasticsearch Java Client reorganized several classes in version 9.0.0 [2] without previous deprecations or shims for old classes. Piotr [1] https://jlbp.dev/JLBP-6 [2] https://www.elastic.co/docs/release-notes/elasticsearch/clients/java/9-0-0 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
