You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@solr.apache.org by Jan Høydahl <ja...@cominvent.com> on 2021/12/13 23:05:24 UTC

Re: Solr 9.0 release blockers

It's been a while. After the 8.11.1 release I'll start pushing for the 9.0 release.
The list of release blockers is currenlty 16 JIRA issues, 11 of which are unassigned. First come first serve :) I'll start working on releaseWizard etc.

Since no new features will be released in 8.11.x, and it will be a huge effort to fork lucene-solr git to only release Solr from that branch, I think we really should strive for the next feature release being 9.0, and that it will happen in Q1 2022.

Do you think we should aim for a 9.0-alpha / beta this time around? That way we could get some early feedback from adventorous users and kill some upgrading-bugs etc.


https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20priority%20%3D%20Blocker%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20%22main%20(9.0)%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC



Jan

> 30. okt. 2021 kl. 14:37 skrev Jason Gerlowski <ge...@gmail.com>:
> 
>> I'll try to create an umbrella JIRA for the "v2 gap"
> 
> Just closing the loop here: see SOLR-15734 and its linked tickets.  I
> created this to cover not just "missing APIs" but anything that seems
> needed to get v2 ready to replace v1 (which seemed to be the larger
> question in this discussion here).
> 
> On Mon, Oct 25, 2021 at 6:11 PM Alexandre Rafalovitch
> <ar...@gmail.com> wrote:
>> 
>> I did some analysis work on that a while ago, though now I realized I
>> did not mark it well with V2 perhaps.
>> 
>> https://issues.apache.org/jira/browse/SOLR-14795
>> 
>> Regards,
>>   Alex.
>> 
>> On Mon, 25 Oct 2021 at 16:12, Jason Gerlowski <ge...@gmail.com> wrote:
>>> 
>>>> Is there an umbrella Jira with open subtasks for every Api that is not covered in V2?
>>> 
>>> Not that I know of, though I'd like to see one.  Checking the name,
>>> semantics, and default values for each parameter of each endpoint for
>>> parity is a big job in itself but it would be helpful, assuming
>>> there's bandwidth to act on it before the underlying APIs change and
>>> leave the "survey" in doubt.  That's been the pitfall of a few other
>>> attempts to catalog the remaining v2 steps, from what I can tell.
>>> 
>>> The closest I've seen to this recently is a Google Sheet that compares
>>> API parity on the "Collection Admin" APIs.
>>> https://docs.google.com/spreadsheets/d/1d3scMpjxSt5HAURkDHmMhQ7FrFuV0umyJyBT0lV_HX0/edit.
>>> I'll try to create an umbrella JIRA for the "v2 gap" that I can
>>> populate from the spreadsheet.  (If I don't get to it in the next
>>> week, assume that my time was taken away and that the task is open for
>>> other volunteers.)
>>> 
>>> On Mon, Oct 25, 2021 at 11:11 AM Cassandra Targett
>>> <ca...@gmail.com> wrote:
>>>> 
>>>> I think there is something wrong with the build of the contrib modules, but I haven't paid close enough attention to this area to know for sure. I didn't see any Jira issues that explain this, but didn't have time for a comprehensive search.
>>>> 
>>>> I downloaded https://ci-builds.apache.org/job/Solr/job/Solr-Artifacts-main/416/ and noticed a couple of issues:
>>>> 
>>>> * None of the READMEs that are in the source appear in their module directories
>>>> * The new contrib/scripting module added in SOLR-14067 is not appearing at all, although there is a solr-scripting-*.jar in the dist/ directory
>>>> * The lucene-libs directories under contrib/analysis-extras and contrib/prometheus-exporter are of course missing, but since the READMEs are missing it's not clear if they're needed (the solr-exporter seemed to start fine without it)
>>>> 
>>>> Am I discovering something that everyone else already knows about? If the READMEs are supposed to be gone now, where are the Ref Guide updates to replace that configuration knowledge?
>>>> 
>>>> On Mon, Oct 25, 2021 at 5:29 AM Jan Høydahl <ja...@cominvent.com> wrote:
>>>>> 
>>>>> Can someone qualified comment on https://issues.apache.org/jira/browse/SOLR-12281regarding what to do wrt index back-compat policy in Solr 9.0? Do we want any code changes?
>>>>> 
>>>>> Jan
>>>>> 
>>>>> 21. okt. 2021 kl. 15:19 skrev Jan Høydahl <ja...@cominvent.com>:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> The Lucene 9.0 release is starting to materialize with a clearn timeline for v8.11 as the last 8.x and then 9.0 immediately after.
>>>>> 
>>>>> We should start preparing for Solr 9.0 by updating the list of real blockers and decide which of those require commits in 8.x (deprecations, preparation for upgrade compat).
>>>>> 
>>>>> Here's the current blocker list for Solr: https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20priority%20%3D%20Blocker%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20%22main%20(9.0)%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>>>>> 
>>>>> <Skjermbilde 2021-10-21 kl. 15.16.06.png>
>>>>> 
>>>>> Please review these. I think several can be closed as unrealistic, and probably new ones can be added. I have started looking at HTTP1 deprecation in SOLR-15223.
>>>>> 
>>>>> 
>>>>> Jan
>>>>> 
>>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>>> For additional commands, e-mail: dev-help@solr.apache.org
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> For additional commands, e-mail: dev-help@solr.apache.org
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>