So maybe, just to get my immediate itch scratched, what if we leave the topic open, since we don’t have a well documented and agreed on deprecation policy (which is why I brought this specific instance of a deprecation up). Then I move forward with having the Full Backup deprecation apply to Solr 11. That gives time for the discussion to proceed. We can always back port it to 10 ;-).
It also sounds like there may be more things to dig into this than just the API removal? Or, API removal is just the first step? > On Sep 2, 2026, at 7:22 AM, Jason Gerlowski <[email protected]> wrote: > > I'd rather see us keep these removals strictly at major-version > boundaries. We want to incentivize folks to upgrade within the latest > major line so that we can get feedback on our recent work, bug > reports, etc. Removing features throughout 10.x makes these upgrades > harder for some folks, and will cause us to get less, slower feedback > from our community. I know there's a maintenance cost that comes with > keeping features around, but I'd argue that if we're worried about > that then we should be doing major releases more frequently. I don't > feel strongly about this ^^ though, and I suspect I'm the minority so > feel free to ignore me. > > The real problem as it pertains to non-incremental backups is that, > despite being deprecated in 9.0, much of the underlying code is still > used by the INSTALLSHARD feature that was added later in 9.x. We can > probably clean up the cosmetics of "/admin/collections?action=BACKUP", > remove the "incremental=true|false" flag, delete some of the tests, > etc. But the bulk of the backing code can't be removed despite the > API-level deprecation : ( > > Best, > > Jason > > > On Mon, Aug 31, 2026 at 3:05 PM Jan Høydahl <[email protected]> wrote: > > > > For things deprecated in 9.0 I think any 10.x is a good chance for removal, > > even if we did not do it in 10.0. > > > > Jan Høydahl > > > > > 31. aug. 2026 kl. 20:05 skrev Eric Pugh <[email protected]>: > > > > > > https://issues.apache.org/jira/browse/SOLR-18358 > > > <https://issues.apache.org/jira/browse/SOLR-18358> is about removing the > > > incremental setting for backups now that full-snapshot has been > > > deprecated, and incremental is just the default. > > > > > > I’m reviewing https://github.com/apache/solr/pull/4808 > > > <https://github.com/apache/solr/pull/4808> is made me wonder about if > > > this should land on Solr 10 or 11? > > > > > > The incremental option as an option was deprecated in 9.0.. However, we > > > have already released 10.0. Is it weird to remove the feature in 10.1? > > > Should we keep the feature through 10x and only remove it in 11? Or are > > > we early enough that removing the option to NOT do an incremental back up > > > in 10x is okay? > > > > > > Eric > > > > > > Disclaimer > > > > > > The information contained in this communication from the sender is > > > confidential. It is intended solely for use by the recipient and others > > > authorized to receive it. If you are not the recipient, you are hereby > > > notified that any disclosure, copying, distribution or taking action in > > > relation of the contents of this information is strictly prohibited and > > > may be unlawful. > > > > > > This email has been scanned for viruses and malware, and may have been > > > automatically archived by Mimecast, a leader in email security and cyber > > > resilience. Mimecast integrates email defenses with brand protection, > > > security awareness training, web security, compliance and other essential > > > capabilities. Mimecast helps protect large and small organizations from > > > malicious activity, human error and technology failure; and to lead the > > > movement toward building a more resilient world. To find out more, visit > > > our website. > > > > --------------------------------------------------------------------- > > 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] Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.
