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]
