> 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.
I disagree that "project still wants to provide a better alternative", at least for CDCR. There is no movement in that direction. Part of the reason people take supporting these features seriously is the threat or deprecation/removal (e.g. HDFS, Velocity, DIH, Autoscaling etc.). The moment we deprecate/remove SolrCell, we will see the better alternatives emerge. And both of them must be removed, even if better alternatives do not emerge. They both must be removed in 9.0. Let us not carry the burden into another major release. On Fri, Aug 28, 2020 at 12:49 PM Jan Høydahl <jan....@cominvent.com> wrote: > 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> 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 > > ~ David > > >
