Admittedly not a great example but it's at least trivial: PR: https://github.com/apache/solr/pull/4757 JIRA: SOLR-18377: remove deprecated DenseVectorField HNSW alias accessors - #4757 Changelog: Remove the deprecated DenseVectorField accessors getHnswMaxConn and getHnswBeamWidth; use getHnswM and getHnswEfConstruction instead. Code in branch_10_0: https://github.com/apache/solr/blob/branch_10_0/solr/core/src/java/org/apache/solr/schema/DenseVectorField.java
Surely in 10.0 we can out-right rename things?! On the other hand, this isn't a very motivating example because it's merely a getter so it's rather trivial to keep a deprecated getter around longer. I can find another example of something fundamentally changing -- not just a getter. On Wed, Aug 26, 2026 at 12:06 PM Jason Gerlowski <[email protected]> wrote: > > If we deprecated something on 10.0 and not 9.x because 9.x doesn't have > the > > new method/class, my instinct is that we may remove the thing at any 10.x > > version (even 10.1) -- need not wait for 11. If we must wait for 11, I > > think this imposes too much of a burden on us. > > Can you please clarify with an example David? I'm not sure I follow... > > In general I worry about removing functionality in (e.g.) 10.2 vs. > 10.0. IMO it's valuable that those minor and bugfix releases are > easy, painless, and "safe" for folks to adopt. i.e. No breaking changes > such as removal, except in really exceptional cases. But I also don't know > I really understand the scenario you're describing, so maybe I'm just > misunderstanding... > > On Fri, Aug 21, 2026 at 11:46 AM David Smiley <[email protected]> wrote: > > > > Great additional points Jan! I just wanted to get the ball rolling here. > > We can probably have an LLM take your points and integrate it into the > wiki > > page. > > > > +1 as well to your point Eric on "lucene.experimental" and > "lucene.internal" > > > > On Fri, Aug 21, 2026 at 10:36 AM Jan Høydahl <[email protected]> > wrote: > > > > > I think any deprecation guideline should recognize that we have several > > > public APIs with a promise of non breaking change in minor versions. > Java > > > code (APIs that 3rd party plugins may rely on) is one. REST APIs is > > > another. CLI tool options is yet another one, config-file format > > > (schema.xml) is yet another. Minimum Java version is an important one. > > > Lucene-index-codec back-compat should be another one but Lucene itself > keep > > > breaking binary index format in minor versions so a downgrade of Solr > from > > > 9.11 to 9.7 e.g. is impossible. That's a separate discussion. Zookeeper > > > strucutre is NOT a public contract, nor is internal APIs, and we > explicitly > > > do not promise anything for things marked as lucene.experimental etc. > > > > > > Also the doc should cover how we deprecate non-Java contracts, i.e. > > > through a deprecation log, a WARN box in ref-guide etc. > > > > > > The primary rule should be no removal of any of the above mentioned > public > > > contracts in minor versions. But with a good reason (such as we did for > > > Metrics and OTEL public contracts) we can make exceptions, which then > gets > > > a prominent mention in Upgrade-Notes for the version and a retro-fitted > > > deprecation. > > > > > > Jan > > > > > > > 21. aug. 2026 kl. 15:41 skrev David Smiley <[email protected]>: > > > > > > > > Rough draft: > > > > > > > > https://cwiki.apache.org/confluence/spaces/SOLR/pages/449282850/Deprecation+Policy > > > > > > > > On Fri, Aug 21, 2026 at 9:07 AM David Smiley <[email protected]> > wrote: > > > > > > > >> Maybe we should have a written deprecation policy somewhere? > > > >> > > > >> Any way... copy-pasting what I wrote in a related thread: > > > >> > > > >> If we deprecated something on 10.0 and not 9.x because 9.x doesn't > have > > > >> the new method/class, my instinct is that we may remove the thing > at any > > > >> 10.x version (even 10.1) -- need not wait for 11. If we must wait > for > > > 11, > > > >> I think this imposes too much of a burden on us. > > > >> > > > >> I guess if folks disagree with my assertion above, committers may > > > >> nonetheless choose to delete in 10.x *anyway* provided that the > > > >> deprecated thing is "internal" (subjectively determined). For > internal > > > >> things, in my strong opinion, the deprecation was a courtesy and/or > is > > > >> equivalent to a TODO comment that can be accomplished at-will. We > > > remove > > > >> interal methods at-will all the time without a deprecation or TODO!! > > > >> > > > >> ~ David Smiley > > > >> Apache Lucene/Solr Search Developer > > > >> http://www.linkedin.com/in/davidwsmiley > > > >> > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
