Yeah I agree; no need to make a prediction on timing/versions at this point.
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Tue, Nov 8, 2022 at 10:32 AM Jason Gerlowski <[email protected]> wrote: > > removing v1 completely on 10.0 should depend on how soon 10.0 is > happening > > I agree on both points: we need to give adequate time for the > ecosystem and users to upgrade, and the major-release cadence will > play a big role there. > > In general I think the "when should we remove v1" question is going to > be really hard to answer this far out. We can try to forecast that > here, but it almost seems futile. That's the main reason that the SIP > is structured around getting to deprecation and **not** around removal > itself. Deprecation is mostly "just" a matter of getting the pre-reqs > done. Removal involves other factors that I don't think we can > predict at this point. > > Best, > > Jason > > On Mon, Nov 7, 2022 at 10:10 PM Noble Paul <[email protected]> wrote: > > > > removing v1 completely on 10.0 should depend on how soon 10.0 is > happening. > > are we prepared to do it within a year? > > > > On Tue, Nov 8, 2022 at 9:47 AM Jan Høydahl <[email protected]> > wrote: > > > > > I'm not against a more aggressive plan, i.e. remove v1 in 10.0 - users > > > will just have to stay longer on 9.x if they don't want to change their > > > apps. > > > My only worry there is that the Solr 10.0 release MAY happen already in > > > Q2/Q3 2023, and that leaves just a few months preparation time for the > > > entire ecosystem to change (other language clients, crawlers, > Blacklight > > > etc). > > > > > > Let's hear other voices on this too. > > > > > > Jan > > > > > > > 7. nov. 2022 kl. 13:41 skrev Jason Gerlowski <[email protected] > >: > > > > > > > > Hi Jan, > > > > > > > > I guess I'd be a bit uncomfortable with deprecating v1 until v2 has > > > > had some decent dog-fooding. That's probably why the SIP suggests > > > > that deprecation coincide with "v2-used-internally": because the > > > > earlier "v2-complete" doesn't mean that anything even uses the v2 API > > > > yet. But that's just my two cents: if there's consensus that we have > > > > enough confidence in v2, or that it'd be valuable to get the > > > > deprecation warning out there earlier, then I can live with that. > > > > > > > > On your second point, I'm a little leery of tying "v2-complete", > > > > "v2-used-internally", and "eventual removal" to any particular > > > > releases - mostly because the timing around our releases has been > > > > somewhat unpredictable. I certainly agree that v1 removal has to > > > > happen on a major-version boundary, and if 10.0 comes around quickly, > > > > then the timeline you suggest seems pretty plausible. But 10.0 might > > > > take much longer (9.0 took 3 years after all), in which case it seems > > > > reasonable to me that v1 could be removed for 10.0 if all the > > > > prerequisites happen early enough in the 9.x line. I guess I'm > > > > worried about a scenario where both 10.x and 11.x are long release > > > > lines, and we end up supporting v1 forever. Any thoughts on that? > > > > > > > > Best, > > > > > > > > Jason > > > > > > > > On Sun, Nov 6, 2022 at 3:04 PM Jan Høydahl <[email protected]> > > > wrote: > > > >> > > > >> Both. > > > >> > > > >> 9x: v2 complete, deprecate v1 (and adding some deprecation noise to > > > logs) > > > >> 10.0 Switch to using v2 internally > > > >> 11.0 Remove v1 > > > >> > > > >> Jan > > > >> > > > >>> 4. nov. 2022 kl. 16:25 skrev Jason Gerlowski < > [email protected]>: > > > >>> > > > >>> Hi Jan, > > > >>> > > > >>> Just trying to make sure I understand your suggestion. Are you > > > suggesting: > > > >>> > > > >>> (1) that we announce v1 as deprecated at "V2-API-Complete" > (instead of > > > >>> the later "v2-API-used-internally")? Or... > > > >>> (2) that we plan "v2-API-used-internally" to coincide with 10.0? > > > >>> (3) Or both? > > > >>> > > > >>> Best, > > > >>> > > > >>> Jason > > > >>> > > > >>> On Mon, Oct 31, 2022 at 5:04 PM Jan Høydahl <[email protected] > > > > > wrote: > > > >>>> > > > >>>> Thanks for a thorough SIP. > > > >>>> > > > >>>> Wrt deprecation plan, could we not have "v2-API-Complete" in e.g. > 9.5 > > > (and deprecate v1). Then we wait until 10.0 with > "v2-API-used-internally", > > > and 11.0 for removing v1. Say we release 10.0 in March 2023, then the > new > > > main will be 11.0 and we can already remove v1 in main. > > > >>>> > > > >>>> Looking forward to code generating SolrJ classes. And perhaps > > > community members actively using some other prog.language will be > empowered > > > to auto generate 90% of such clients. > > > >>>> > > > >>>> Jan > > > >>>> > > > >>>>> 31. okt. 2022 kl. 21:23 skrev Jason Gerlowski < > [email protected] > > > >: > > > >>>>> > > > >>>>> Hey all, > > > >>>>> > > > >>>>> This morning I published SIP-16, which proposes the changes > necessary > > > >>>>> to "finish" (i.e. plug coverage gaps and polish) Solr's v2 APIs > and a > > > >>>>> path to deprecating Solr's v1 APIs. > > > >>>>> > > > >>>>> The SIP can be found here: > > > >>>>> > > > > https://cwiki.apache.org/confluence/display/SOLR/SIP-16%3A+Polish+and+Prepare+v2+APIs+for+v1+Deprecation > > > >>>>> > > > >>>>> Please read the SIP description and come back here for > discussion. > > > As > > > >>>>> the discussion progresses we will update the SIP page with any > > > >>>>> outcomes and eventually move things to a VOTE (or lazy > consensus). > > > >>>>> > > > >>>>> Looking forward to hearing your feedback! > > > >>>>> > > > >>>>> Best, > > > >>>>> > > > >>>>> Jason > > > >>>>> > > > >>>>> > --------------------------------------------------------------------- > > > >>>>> 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] > > > >>>> > > > >>> > > > >>> > --------------------------------------------------------------------- > > > >>> 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] > > > >> > > > > > > > > --------------------------------------------------------------------- > > > > 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] > > > > > > > > > > -- > > ----------------------------------------------------- > > Noble Paul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
