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]
