> 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]
