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
>