|
|
|
|
Hi committers,
I'll share a link to the "Doodle Poll" to figure out a time that suits most of us. You'll be able to find a link to the poll on #lucene-dev and #solr-dev channels on the ASF Slack. Please email me to ask for the link if you are a committer who isn't on Slack and would like to participate.
For this virtual committer meeting and future ones:
- This is in the spirit of committer meetings co-located with conferences. ASF policy says that no "decisions" can be made in such a venue. We make decisions on this dev list and indirectly via JIRA out in the open and with the opportunity for anyone to comment.
- Who: Committer-only
- Video chat with option of audio dial-in. This time I will use Google Hangout but open to using something else.
- I wouldn't be recording this, but would provide detailed meeting notes that I can share with everyone who signs up.
- Published notes: I (or someone) will take written meeting notes that are ultimately published for anyone to see (not restricted to those invited). They will be transmitted to the dev list.
--
|
|
|
Thanks so much for organizing this Anshum! We are much overdue. ~ David Smiley Apache Lucene/Solr Search Developer Hi committers,
I'll share a link to the "Doodle Poll" to figure out a time that suits most of us. You'll be able to find a link to the poll on #lucene-dev and #solr-dev channels on the ASF Slack. Please email me to ask for the link if you are a committer who isn't on Slack and would like to participate.
For this virtual committer meeting and future ones:
- This is in the spirit of committer meetings co-located with conferences. ASF policy says that no "decisions" can be made in such a venue. We make decisions on this dev list and indirectly via JIRA out in the open and with the opportunity for anyone to comment.
- Who: Committer-only
- Video chat with option of audio dial-in. This time I will use Google Hangout but open to using something else.
- I wouldn't be recording this, but would provide detailed meeting notes that I can share with everyone who signs up.
- Published notes: I (or someone) will take written meeting notes that are ultimately published for anyone to see (not restricted to those invited). They will be transmitted to the dev list.
--
|
|
|
I would like to explicitly propose that we do not attempt to bring up the Solr reference impl branch, since I'm reasonably sure that will take up a full hour by itself. I chatted with Mark about it this morning, and he said he's working on a wiki page and then we can take it from there (next meeting, next month?) Thanks so much for organizing this Anshum! We are much overdue. ~ David Smiley Apache Lucene/Solr Search Developer
Hi committers,
I'll share a link to the "Doodle Poll" to figure out a time that suits most of us. You'll be able to find a link to the poll on #lucene-dev and #solr-dev channels on the ASF Slack. Please email me to ask for the link if you are a committer who isn't on Slack and would like to participate.
For this virtual committer meeting and future ones:
- This is in the spirit of committer meetings co-located with conferences. ASF policy says that no "decisions" can be made in such a venue. We make decisions on this dev list and indirectly via JIRA out in the open and with the opportunity for anyone to comment.
- Who: Committer-only
- Video chat with option of audio dial-in. This time I will use Google Hangout but open to using something else.
- I wouldn't be recording this, but would provide detailed meeting notes that I can share with everyone who signs up.
- Published notes: I (or someone) will take written meeting notes that are ultimately published for anyone to see (not restricted to those invited). They will be transmitted to the dev list.
--
|
|
|
+1 :)
Also, just a reminder for folks to put up the topics they want to discuss, preferably with the time needed on the confluence page linked above.
I would like to explicitly propose that we do not attempt to bring up the Solr reference impl branch, since I'm reasonably sure that will take up a full hour by itself. I chatted with Mark about it this morning, and he said he's working on a wiki page and then we can take it from there (next meeting, next month?)
Thanks so much for organizing this Anshum! We are much overdue. ~ David Smiley Apache Lucene/Solr Search Developer
Hi committers,
I'll share a link to the "Doodle Poll" to figure out a time that suits most of us. You'll be able to find a link to the poll on #lucene-dev and #solr-dev channels on the ASF Slack. Please email me to ask for the link if you are a committer who isn't on Slack and would like to participate.
For this virtual committer meeting and future ones:
- This is in the spirit of committer meetings co-located with conferences. ASF policy says that no "decisions" can be made in such a venue. We make decisions on this dev list and indirectly via JIRA out in the open and with the opportunity for anyone to comment.
- Who: Committer-only
- Video chat with option of audio dial-in. This time I will use Google Hangout but open to using something else.
- I wouldn't be recording this, but would provide detailed meeting notes that I can share with everyone who signs up.
- Published notes: I (or someone) will take written meeting notes that are ultimately published for anyone to see (not restricted to those invited). They will be transmitted to the dev list.
--
--
|
|
|
What good are these meetings if the most important issues concerning the community are off limits? +1 :)
Also, just a reminder for folks to put up the topics they want to discuss, preferably with the time needed on the confluence page linked above.
I would like to explicitly propose that we do not attempt to bring up the Solr reference impl branch, since I'm reasonably sure that will take up a full hour by itself. I chatted with Mark about it this morning, and he said he's working on a wiki page and then we can take it from there (next meeting, next month?)
Thanks so much for organizing this Anshum! We are much overdue. ~ David Smiley Apache Lucene/Solr Search Developer
Hi committers,
I'll share a link to the "Doodle Poll" to figure out a time that suits most of us. You'll be able to find a link to the poll on #lucene-dev and #solr-dev channels on the ASF Slack. Please email me to ask for the link if you are a committer who isn't on Slack and would like to participate.
For this virtual committer meeting and future ones:
- This is in the spirit of committer meetings co-located with conferences. ASF policy says that no "decisions" can be made in such a venue. We make decisions on this dev list and indirectly via JIRA out in the open and with the opportunity for anyone to comment.
- Who: Committer-only
- Video chat with option of audio dial-in. This time I will use Google Hangout but open to using something else.
- I wouldn't be recording this, but would provide detailed meeting notes that I can share with everyone who signs up.
- Published notes: I (or someone) will take written meeting notes that are ultimately published for anyone to see (not restricted to those invited). They will be transmitted to the dev list.
--
--
|
|
|
I agree with Mike, the ref-branch is a topic that will take much more than an hour. I don't think the idea is to limit discussion around the ref-branch, but instead to separate it out so that other topics are given the time that they need.
- Houston On Thu, Jan 7, 2021 at 2:08 PM Ishan Chattopadhyaya < [hidden email]> wrote: What good are these meetings if the most important issues concerning the community are off limits?
+1 :)
Also, just a reminder for folks to put up the topics they want to discuss, preferably with the time needed on the confluence page linked above.
I would like to explicitly propose that we do not attempt to bring up the Solr reference impl branch, since I'm reasonably sure that will take up a full hour by itself. I chatted with Mark about it this morning, and he said he's working on a wiki page and then we can take it from there (next meeting, next month?)
Thanks so much for organizing this Anshum! We are much overdue. ~ David Smiley Apache Lucene/Solr Search Developer
Hi committers,
I'll share a link to the "Doodle Poll" to figure out a time that suits most of us. You'll be able to find a link to the poll on #lucene-dev and #solr-dev channels on the ASF Slack. Please email me to ask for the link if you are a committer who isn't on Slack and would like to participate.
For this virtual committer meeting and future ones:
- This is in the spirit of committer meetings co-located with conferences. ASF policy says that no "decisions" can be made in such a venue. We make decisions on this dev list and indirectly via JIRA out in the open and with the opportunity for anyone to comment.
- Who: Committer-only
- Video chat with option of audio dial-in. This time I will use Google Hangout but open to using something else.
- I wouldn't be recording this, but would provide detailed meeting notes that I can share with everyone who signs up.
- Published notes: I (or someone) will take written meeting notes that are ultimately published for anyone to see (not restricted to those invited). They will be transmitted to the dev list.
--
--
|
|
|
Can we plan a long overdue meeting to talk about nothing else but the so-called reference branch? The topic isn't forbidden, but it'd take all the oxygen out of the room to try to talk about that and anything else in the same meeting. ~ David Smiley Apache Lucene/Solr Search Developer I agree with Mike, the ref-branch is a topic that will take much more than an hour. I don't think the idea is to limit discussion around the ref-branch, but instead to separate it out so that other topics are given the time that they need.
- Houston
On Thu, Jan 7, 2021 at 2:08 PM Ishan Chattopadhyaya < [hidden email]> wrote: What good are these meetings if the most important issues concerning the community are off limits?
+1 :)
Also, just a reminder for folks to put up the topics they want to discuss, preferably with the time needed on the confluence page linked above.
I would like to explicitly propose that we do not attempt to bring up the Solr reference impl branch, since I'm reasonably sure that will take up a full hour by itself. I chatted with Mark about it this morning, and he said he's working on a wiki page and then we can take it from there (next meeting, next month?)
Thanks so much for organizing this Anshum! We are much overdue. ~ David Smiley Apache Lucene/Solr Search Developer
Hi committers,
I'll share a link to the "Doodle Poll" to figure out a time that suits most of us. You'll be able to find a link to the poll on #lucene-dev and #solr-dev channels on the ASF Slack. Please email me to ask for the link if you are a committer who isn't on Slack and would like to participate.
For this virtual committer meeting and future ones:
- This is in the spirit of committer meetings co-located with conferences. ASF policy says that no "decisions" can be made in such a venue. We make decisions on this dev list and indirectly via JIRA out in the open and with the opportunity for anyone to comment.
- Who: Committer-only
- Video chat with option of audio dial-in. This time I will use Google Hangout but open to using something else.
- I wouldn't be recording this, but would provide detailed meeting notes that I can share with everyone who signs up.
- Published notes: I (or someone) will take written meeting notes that are ultimately published for anyone to see (not restricted to those invited). They will be transmitted to the dev list.
--
--
|
|
|
Agree. That is what all of us intend to do, just that clubbing the ref_branch discussion with this meeting will not leave us with the bandwidth to discuss much else.
As Mike suggested, let's schedule another meeting to discuss specifically the ref_branch and the intention around that. Can we plan a long overdue meeting to talk about nothing else but the so-called reference branch? The topic isn't forbidden, but it'd take all the oxygen out of the room to try to talk about that and anything else in the same meeting. ~ David Smiley Apache Lucene/Solr Search Developer
I agree with Mike, the ref-branch is a topic that will take much more than an hour. I don't think the idea is to limit discussion around the ref-branch, but instead to separate it out so that other topics are given the time that they need.
- Houston
On Thu, Jan 7, 2021 at 2:08 PM Ishan Chattopadhyaya < [hidden email]> wrote: What good are these meetings if the most important issues concerning the community are off limits?
+1 :)
Also, just a reminder for folks to put up the topics they want to discuss, preferably with the time needed on the confluence page linked above.
I would like to explicitly propose that we do not attempt to bring up the Solr reference impl branch, since I'm reasonably sure that will take up a full hour by itself. I chatted with Mark about it this morning, and he said he's working on a wiki page and then we can take it from there (next meeting, next month?)
Thanks so much for organizing this Anshum! We are much overdue. ~ David Smiley Apache Lucene/Solr Search Developer
Hi committers,
I'll share a link to the "Doodle Poll" to figure out a time that suits most of us. You'll be able to find a link to the poll on #lucene-dev and #solr-dev channels on the ASF Slack. Please email me to ask for the link if you are a committer who isn't on Slack and would like to participate.
For this virtual committer meeting and future ones:
- This is in the spirit of committer meetings co-located with conferences. ASF policy says that no "decisions" can be made in such a venue. We make decisions on this dev list and indirectly via JIRA out in the open and with the opportunity for anyone to comment.
- Who: Committer-only
- Video chat with option of audio dial-in. This time I will use Google Hangout but open to using something else.
- I wouldn't be recording this, but would provide detailed meeting notes that I can share with everyone who signs up.
- Published notes: I (or someone) will take written meeting notes that are ultimately published for anyone to see (not restricted to those invited). They will be transmitted to the dev list.
--
--
--
|
|
|
Perhaps there will be time at the end of this meeting (in 30min now) to discuss "ref branch" stuff? Even if there's only 10min, I'd love to get an update on that! ~ David Smiley Apache Lucene/Solr Search Developer Agree. That is what all of us intend to do, just that clubbing the ref_branch discussion with this meeting will not leave us with the bandwidth to discuss much else.
As Mike suggested, let's schedule another meeting to discuss specifically the ref_branch and the intention around that.
Can we plan a long overdue meeting to talk about nothing else but the so-called reference branch? The topic isn't forbidden, but it'd take all the oxygen out of the room to try to talk about that and anything else in the same meeting. ~ David Smiley Apache Lucene/Solr Search Developer
I agree with Mike, the ref-branch is a topic that will take much more than an hour. I don't think the idea is to limit discussion around the ref-branch, but instead to separate it out so that other topics are given the time that they need.
- Houston
On Thu, Jan 7, 2021 at 2:08 PM Ishan Chattopadhyaya < [hidden email]> wrote: What good are these meetings if the most important issues concerning the community are off limits?
+1 :)
Also, just a reminder for folks to put up the topics they want to discuss, preferably with the time needed on the confluence page linked above.
I would like to explicitly propose that we do not attempt to bring up the Solr reference impl branch, since I'm reasonably sure that will take up a full hour by itself. I chatted with Mark about it this morning, and he said he's working on a wiki page and then we can take it from there (next meeting, next month?)
Thanks so much for organizing this Anshum! We are much overdue. ~ David Smiley Apache Lucene/Solr Search Developer
Hi committers,
I'll share a link to the "Doodle Poll" to figure out a time that suits most of us. You'll be able to find a link to the poll on #lucene-dev and #solr-dev channels on the ASF Slack. Please email me to ask for the link if you are a committer who isn't on Slack and would like to participate.
For this virtual committer meeting and future ones:
- This is in the spirit of committer meetings co-located with conferences. ASF policy says that no "decisions" can be made in such a venue. We make decisions on this dev list and indirectly via JIRA out in the open and with the opportunity for anyone to comment.
- Who: Committer-only
- Video chat with option of audio dial-in. This time I will use Google Hangout but open to using something else.
- I wouldn't be recording this, but would provide detailed meeting notes that I can share with everyone who signs up.
- Published notes: I (or someone) will take written meeting notes that are ultimately published for anyone to see (not restricted to those invited). They will be transmitted to the dev list.
--
--
--
|
|
|
The notes are available on the confluence page for the meeting, and copied here for posterity:
9.0 Release Planing - Will release Lucene/Solr separately
- Vector work in Lucene, lots of work in Solr as well burning to be released.
- 8.x releases could continue… (8.9 Solr depending on 8.8 Lucene?)
- Reminder that there are issues with new minors after a major release (8.9 after a 9.0) - somebody to research.
- Action Item: Label as blockers any issues that MUST be resolved before a release.
- Solr packages need an upgrade strategy (minor-minor, minor-major)
- May consider decoupling organizational change from code change.
- Release train keeps getting bigger and bigger?
- Action item: define critical path to releasing split code.
Solr TLP Creation - Should happen before 9.0
- Ton of interest initially, but activity has since seemed to slow down
- Just more forward with everybody current on the PMC/Committer list?
- Several people claim that it “feels wrong” but difficult to articulate the actual concerns
- Potential compromise is to mark folks as emeritus on website, while still providing commit bit
- Auto-opt-in for anybody active in the past X years
- Smiley volunteered to reach out to all committers to ascertain their desired relationship with Solr TLP.
- Important to have communication for restoring status for people who may have been missed.
- …And then send board resolution
- Expect all of this to take ~month between vote and next board meeting/report.
Solr Sandbox - Isolation of components that need a separate release cadence
- Goal is to work and contribute directly to Apache (some companies have issues with personal projects)
- Apache Commons had a “commons sandbox” with lower barrier to entry and lower expectations
- Solr Extras, Solr Contrib, Solr Commons?
- First party packages should still live in the repo
- - example LTR?
- - example Streaming Expressions that could work with multiple versions
- Best candidates are contribs that “sit there” once they are done
Docker Image - Post 9.0, plan to provide Docker images via solr repo instead of docker-solr repo
- How is it going to be released - official image or apache image or ???
- Need to understand verification steps for “official” images
- Can we release at the same time (Release and Docker)
- Are these releasable according to ASF policy (source v binary)
- Likely need to be released to ASF org on docker hub.
Hi committers,
I'll share a link to the "Doodle Poll" to figure out a time that suits most of us. You'll be able to find a link to the poll on #lucene-dev and #solr-dev channels on the ASF Slack. Please email me to ask for the link if you are a committer who isn't on Slack and would like to participate.
For this virtual committer meeting and future ones:
- This is in the spirit of committer meetings co-located with conferences. ASF policy says that no "decisions" can be made in such a venue. We make decisions on this dev list and indirectly via JIRA out in the open and with the opportunity for anyone to comment.
- Who: Committer-only
- Video chat with option of audio dial-in. This time I will use Google Hangout but open to using something else.
- I wouldn't be recording this, but would provide detailed meeting notes that I can share with everyone who signs up.
- Published notes: I (or someone) will take written meeting notes that are ultimately published for anyone to see (not restricted to those invited). They will be transmitted to the dev list.
--
|
|
|
9.0 Release Planing - Reminder that there are issues with new minors after a major release (8.9 after a 9.0) - somebody to research.
The main challenge with this is backwards compatibility testing. If you release 8.9 after 9.0, there is nothing in the release process that tests that Lucene 9 can read 8.9 indices even though that is a guarantee we provide. It can be tested manually (we have done it a couple times) but this is quite painful and not as reliable as having it tested on every CI build prior to the release, so we prefer avoiding releasing new minors after a new major.
This is mostly a problem for Lucene so once Lucene and Solr have distinct release cycles, Solr could potentially do this, e.g. release Solr 9.9 after 10.0 is out (as long as Solr 9.9 keeps depending on the same Lucene version as Solr 9.8).
|
|
|
The question came up in the context of a discussion about whether it
could be sensible for Lucene 9.0 to be released without Solr 9.0 being
released. I think we're struggling a bit to conceptualize how the next
release will work: release 9.0 as we do today and delay the split
until after, coordinate the releases of Lucene 9.0 and Solr 9.0, but
separately, or try to decouple them somehow.
On Thu, Jan 14, 2021 at 1:20 PM Adrien Grand < [hidden email]> wrote:
>
> Le jeu. 14 janv. 2021 à 18:16, Mike Drob < [hidden email]> a écrit :
>>
>>
>> 9.0 Release Planing
>>
>> Reminder that there are issues with new minors after a major release (8.9 after a 9.0) - somebody to research.
>
>
> The main challenge with this is backwards compatibility testing. If you release 8.9 after 9.0, there is nothing in the release process that tests that Lucene 9 can read 8.9 indices even though that is a guarantee we provide. It can be tested manually (we have done it a couple times) but this is quite painful and not as reliable as having it tested on every CI build prior to the release, so we prefer avoiding releasing new minors after a new major.
>
> This is mostly a problem for Lucene so once Lucene and Solr have distinct release cycles, Solr could potentially do this, e.g. release Solr 9.9 after 10.0 is out (as long as Solr 9.9 keeps depending on the same Lucene version as Solr 9.8).
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
|
|
|
Thanks for commenting Adrien; I was hoping to get your input on this!
9.0 Release Planing - Reminder that there are issues with new minors after a major release (8.9 after a 9.0) - somebody to research.
The main challenge with this is backwards compatibility testing. If you release 8.9 after 9.0, there is nothing in the release process that tests that Lucene 9 can read 8.9 indices even though that is a guarantee we provide. It can be tested manually (we have done it a couple times) but this is quite painful and not as reliable as having it tested on every CI build prior to the release, so we prefer avoiding releasing new minors after a new major.
I'm not familiar with why the testing needs to be manual instead of automated. After having a RC of 8.9, couldn't we add the back-compat indices to branch_9x and check that 9.0 is happy with them (running applicable automated tests) as a precondition for releasing 8.9? Regardless, you say we've done it before, and we can do it again. I think it's likely it'll happen. This is mostly a problem for Lucene so once Lucene and Solr have distinct release cycles, Solr could potentially do this, e.g. release Solr 9.9 after 10.0 is out (as long as Solr 9.9 keeps depending on the same Lucene version as Solr 9.8).
Right; understood.
|
|
|
I'm not familiar with why the testing needs to be manual instead of automated. After having a RC of 8.9, couldn't we add the back-compat indices to branch_9x and check that 9.0 is happy with them (running applicable automated tests) as a precondition for releasing 8.9? Regardless, you say we've done it before, and we can do it again. I think it's likely it'll happen.
Right, this is what needs to be done (though ideally on 9.x tags rather than branch_9x). I called it manual because it requires special action and is neither checked by Jenkins nor by any of the people who run the smoke tester on release artifacts. My personal take on this is that the risk of having a backward compatibility gap or the cost of investing into automated testing for this outweigh the benefits we can get from releasing new minors of the previous major. I couldn't attend this meeting, what is the motivation for keeping releasing 8.x after 9.0 is out?
For the record, I am less worried about patch releases, which have much smaller scopes and never change file formats. So I'd be fine with doing 8.lastest patch releases after 9.0 is out, similarly to how we released 7.7.3 after 8.0.
-- Adrien
|
|
|
Can we not write in 8.9 notes that upgrades to 9.0 may work but is not officially supported, and that they should wait for 9.1. Then add 8.9 back compact tests to 9.1. Am I missing something? Jan Høydahl I'm not familiar with why the testing needs to be manual instead of automated. After having a RC of 8.9, couldn't we add the back-compat indices to branch_9x and check that 9.0 is happy with them (running applicable automated tests) as a precondition for releasing 8.9? Regardless, you say we've done it before, and we can do it again. I think it's likely it'll happen.
Right, this is what needs to be done (though ideally on 9.x tags rather than branch_9x). I called it manual because it requires special action and is neither checked by Jenkins nor by any of the people who run the smoke tester on release artifacts. My personal take on this is that the risk of having a backward compatibility gap or the cost of investing into automated testing for this outweigh the benefits we can get from releasing new minors of the previous major. I couldn't attend this meeting, what is the motivation for keeping releasing 8.x after 9.0 is out?
For the record, I am less worried about patch releases, which have much smaller scopes and never change file formats. So I'd be fine with doing 8.lastest patch releases after 9.0 is out, similarly to how we released 7.7.3 after 8.0.
-- Adrien
|
|
|
I don't think you are missing something, Jan, but I would rather not introduce exceptions in order to keep things simple for users.
It's not fully clear to me why this question is important in the context of 9.0, is it because we are considering having a long delay between Lucene 9.0 and Solr 9.0 and we would like to avoid keeping Solr without a release for too long? Can we not write in 8.9 notes that upgrades to 9.0 may work but is not officially supported, and that they should wait for 9.1. Then add 8.9 back compact tests to 9.1. Am I missing something? Jan Høydahl I'm not familiar with why the testing needs to be manual instead of automated. After having a RC of 8.9, couldn't we add the back-compat indices to branch_9x and check that 9.0 is happy with them (running applicable automated tests) as a precondition for releasing 8.9? Regardless, you say we've done it before, and we can do it again. I think it's likely it'll happen.
Right, this is what needs to be done (though ideally on 9.x tags rather than branch_9x). I called it manual because it requires special action and is neither checked by Jenkins nor by any of the people who run the smoke tester on release artifacts. My personal take on this is that the risk of having a backward compatibility gap or the cost of investing into automated testing for this outweigh the benefits we can get from releasing new minors of the previous major. I couldn't attend this meeting, what is the motivation for keeping releasing 8.x after 9.0 is out?
For the record, I am less worried about patch releases, which have much smaller scopes and never change file formats. So I'd be fine with doing 8.lastest patch releases after 9.0 is out, similarly to how we released 7.7.3 after 8.0.
-- Adrien
-- Adrien
|
|
|
It's not fully clear to me why this question is important in the context of 9.0, is it because we are considering having a long delay between Lucene 9.0 and Solr 9.0 and we would like to avoid keeping Solr without a release for too long?
Yes.
Alternatively, I suppose Solr could try and figure out how to release a Solr 8.9 using Lucene 8.8 or if necessary some 8.9-SNAPSHOT. It would be a non-standard release of course, ideally performed by someone who is well familiar with doing Solr releases in order to ensure there is no concurrent Lucene release.
~ David
|
|
|
Out of curiosity, why do we expect a long delay between Lucene 9 and Solr 9, is it because we have many Solr JIRAs that need to go in Solr 9? It's not fully clear to me why this question is important in the context of 9.0, is it because we are considering having a long delay between Lucene 9.0 and Solr 9.0 and we would like to avoid keeping Solr without a release for too long?
Yes.
Alternatively, I suppose Solr could try and figure out how to release a Solr 8.9 using Lucene 8.8 or if necessary some 8.9-SNAPSHOT. It would be a non-standard release of course, ideally performed by someone who is well familiar with doing Solr releases in order to ensure there is no concurrent Lucene release.
~ David
-- Adrien
|
|
|
There was some concern about the tasks needed for the release that are
*not* code-related: figure out how to maintain code repository, make
any needed changes to build system and release process; create a
different web site, and I'm sure other things I'm forgetting.
Personally, I hope these don't turn out to be too great in scope, but
they are somewhat unknown in scope right now. There may also be
code-related issues that I'm not aware of.
On Sun, Jan 17, 2021 at 4:51 PM Adrien Grand < [hidden email]> wrote:
>
> Out of curiosity, why do we expect a long delay between Lucene 9 and Solr 9, is it because we have many Solr JIRAs that need to go in Solr 9?
>
> On Sat, Jan 16, 2021 at 11:54 PM David Smiley < [hidden email]> wrote:
>>
>> On Sat, Jan 16, 2021 at 4:50 PM Adrien Grand < [hidden email]> wrote:
>>>
>>> It's not fully clear to me why this question is important in the context of 9.0, is it because we are considering having a long delay between Lucene 9.0 and Solr 9.0 and we would like to avoid keeping Solr without a release for too long?
>>
>>
>> Yes.
>>
>> Alternatively, I suppose Solr could try and figure out how to release a Solr 8.9 using Lucene 8.8 or if necessary some 8.9-SNAPSHOT. It would be a non-standard release of course, ideally performed by someone who is well familiar with doing Solr releases in order to ensure there is no concurrent Lucene release.
>>
>> ~ David
>
>
>
> --
> Adrien
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
|
|
Locked
