As amusing as the pattern has been (6.6, 7.7, 8.8?) we don't actually have to release 9 point releases (9.9) before 10.0 :). I'd advocate that some things we don't feel we can remove in 9.0 hang on for a few point releases and when we're ready to ditch them we declare 10.0. if that's after 9.2 or 9.3 that's fine...
I agree that to drop support for something major we should hold a [VOTE]. Additionally I suggest that the vote thread should include specification of the timeline (in terms of releases) for deprecate/removal -Gus On Fri, Aug 28, 2020 at 10:50 AM Jan Høydahl <[email protected]> wrote: > Noble, we all agree on those principles and that direction. > > But 9.0 is not the last chance to remove things. I think we must decide on > a feature-by feature basis: > - Whether the feature should remain a ASF maintained feature or not > - If yes, we should make it into a 1st party package distributed in our > own repo > - If no, we must decide what is the right time to remove it from the > distro. > - If an alternative package already exists, it can be removed in next > major > - If not, we must decide how long time our users need to prepare an > alternative (3rd party pkg or home-grown) > > When propose to stop maintaining a feature as part of the project, a > [VOTE] thread is an excellent way to make such a decision. > > Jan > > > 28. aug. 2020 kl. 14:35 skrev Noble Paul <[email protected]>: > > > > We do not have to provide all features. Whatever feature we provide, > > it should be reasonably bug free, performant and stable. > > > > There is no point in carrying around a lot of baggage if we are barely > > able to carry it. There are a lot of "dark areas" in Solr which nobody > > pays attention to. Those features should be removed altogether. If > > there are committers who wish to actively support it , we can maintain > > them in packages. If, not we should euthanize them gracefully > > > > On Fri, Aug 28, 2020 at 5:43 PM Ishan Chattopadhyaya > > <[email protected]> wrote: > >> > >>> 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 <[email protected]> > 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 > 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 <[email protected]>: > >>> > >>> > >>> On Thu, Aug 27, 2020 at 7:03 PM Ishan Chattopadhyaya < > [email protected]> 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 > >>> > >>> > > > > > > -- > > ----------------------------------------------------- > > Noble Paul > > > > --------------------------------------------------------------------- > > 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] > > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
