Hi, I phrased that sentence in the roadmap Wiki, but I think the wording is more conservative than need-be. The intent was really to avoid a situation where 9.0 goes out the door «tomorrow» without a replacement for a popular feature that the community really wants. I attempted a re-phrase of that sentence after the meeting yesterday, but did not immediately find a better wording.
Personally I think a deprecation in 8.6 can be removed in 9.0 (there’ll be several months and 2’ish releases in between) if it has a well known, released replacement/package. And let’s link to those packages in ref-guide and link to the ref-guide from the release-note. I.e. ref-guide <https://nightlies.apache.org/Lucene/Solr-reference-guide-master/uploading-structured-data-store-data-with-the-data-import-handler.html> currently ways DIH is to be removed, perhaps that page could instead explain how to obtain the package, and at the same time encourage users to contribute to maintaining it? The consensus from yesterday seems to be that stuff with a released replacement can/should be removed in 9.0, but for CDCR and SolrCell, where the proejct still wants to provide a better alternative, they can remain deprecated 9.x. In particular for SolrCell we can’t imagine how many users it has out there. Even after inventing its successor based on TikaServer, integrated in SolrJ or whatever, I would advocate for the good-old ExtractingRequestHandler to be available as a package for a few releases to come. Wrt whether something could be removed in 9.1 as long as it was deprecated in 8.x, I would initially say YES, at least legally/technically. We’re not breaking any back-compat promise as long as it has been prominently flagged as deprecated for so long. However, I can see how people not reading documentation downloads 9.0.0, starts using a deprecated feature and then complains when it is gone in 9.3 :) We also have an option to release Solr 10.0 (Solr X) sooner rather than later (even on Lucene 9.x). Looks like we have tons of major goodies lined up - it won’t all need to land in 9.0. Guess that’s what the Roadmap page is there for. So as David says, let’s start placing the removal JIRAs into the roadmap page and see if we’re still on the same page? Jan > 28. aug. 2020 kl. 07:43 skrev David Smiley <dsmi...@apache.org>: > > > On Thu, Aug 27, 2020 at 7:03 PM Ishan Chattopadhyaya > <ichattopadhy...@gmail.com <mailto:ichattopadhy...@gmail.com>> wrote: > > I find it highly depressing that we can't, *in a major release*, manage to > > get rid of our deprecations -- particularly for code that has a new home > > and is packaged in a form that is trivial to install (thanks to our new > > awesome package manager). > > I'm not sure why you think "we can't". I can't even remember a single > committer standing in the way of removing those *that already have a > package*. > > Okay, maybe I read the intent wrong. I can see the example given was about > Solr Cell, which apparently has no new home, so I'm +0 with keeping it for > 9.0. > > Also, on the roadmap cwiki: > > We should not remove all features/APIs deprecated in 8.x yet, to give users a > path to upgrade to 9.x without all the extra noise. Deprecated features can > be removed in a later 9.x release, when the new alternative is solid and well > known. > > Again, maybe I'm misreading but I'd like to us to manage to remove a lot of > deprecated stuff as the norm. There will be exceptions to the norm -- Solr > Cell, CDCR. To make this point clear, I wish to add to the roadmap, Solr 9.0 > table, first row, saying basically "Remove lots of deprecated stuff" with > some JIRAs linked like https://issues.apache.org/jira/browse/SOLR-13138 > <https://issues.apache.org/jira/browse/SOLR-13138> > > ~ David
