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/21 15:56:47 UTC
Solr 9.0.0 release in February
Hi,
Solr's next feature release will be 9.0 (as 8x is in bugfix mode).
Let's not even think about hacking an 8.12 release based on lucene-solr 8x branch. It will be ugly.
The "Solr 9.0 release blockers" thread <https://lists.apache.org/thread/m7k2gvgxldkns7jqjnw1ghhqx7s3tpl1> was started exactly 2 months ago to try to prepare us. But we're moving slowly. The same happened for Lucene, until the 9.0 release :) So I'll start the train right now...
I propose the following rough roadmap:
December: Cut branch_9x next week and enter feature freeze on that branch
January: Remove blockers, prepare build & release machinery, including Docker
February: Cut branch_9_0 and build RC1 - branch_9x is again re-opened for new features
I volunteer as RM.
Wrt blockers, we need to be tough on ourselves and ask the question "Is it possible to release 9.0 without this?"..
At the end of January we should have only a few real blockers left, that are all actively in progress.
The delay between branch_9x and branch_9_0 is to avoid having to backport everything twice during the hardening phase.
Jan
Re: Solr 9.0.0 release in February
Posted by Jan Høydahl <ja...@cominvent.com>.
It is obviously confusing to treat 9x banch as release branch and main as both 10.0 and 9.next.
I can symphatize with wanting a place to land 9.1 backports right now.
If we continue with current setup and wait with cutting 9_0, committers could adapt a workflow like this
* Merge your PR to main
* Create a feature branch from branch_9x with the backport, and open a PR against branch_9x (dropdown in GitHub9
* Whenever you do followup commits or bug fixes on main for your new feature, backport those to the 9x feature branch
* When branch_9_0 is created, merge the PRs
It's a bit more involved, but so is having three live branches that needs cherry-picking for all the stabilization work in the coming weeks. Perhaps they are equally burdensome?
Jan
> 7. jan. 2022 kl. 19:39 skrev Houston Putman <ho...@gmail.com>:
>
> If we are doing a "feature freeze" for 9.0, then I think we need to cut branch_9_0. Otherwise there is going to be at least a month of features slated for 9.1 that only get committed to 10x. There are bound to be tickets/commits that fall through and don't end up on branch_9x even though they are supposed to.
>
> In my original comment I mentioned that "unless there is a need for branch_9x and branch_9_0 to differ". There already is, so let's go ahead and cut it.
>
> On Tue, Jan 4, 2022 at 3:34 AM Jan Høydahl <jan.asf@cominvent.com <ma...@cominvent.com>> wrote:
> Agree. Will cut the branch tomorrow or Thursday.
>
> Current list of 9.0 blockers: https://issues.apache.org/jira/issues/?filter=12351219 <https://issues.apache.org/jira/issues/?filter=12351219>
> Please jump in and help with the ones you care for.
>
> PS: I found a bunch of issues assigned to the "9.0" fixVersion, I moved them all to "main (9.0)" which is the correct version to use for 9.0.
>
> Jan
>
>> 3. jan. 2022 kl. 20:08 skrev David Smiley <dsmiley@apache.org <ma...@apache.org>>:
>>
>> I completely agree with Houston; let's not create branch_9_0 yet.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
>>
>> On Mon, Jan 3, 2022 at 11:36 AM Houston Putman <houstonputman@gmail.com <ma...@gmail.com>> wrote:
>> I think its fine to start with just branch_9x until we are ready to actually do the release, even if it is unconventional for our processes. There’s no need to have a branch_9_0 until there are actual reasons that 9x and 9_0 would differ (i.e. 9.0.0 is ready to be released and people want to add things for 9.1.0).
>>
>> On Mon, Jan 3, 2022 at 10:31 AM Jan Høydahl <jan.asf@cominvent.com <ma...@cominvent.com>> wrote:
>> Happy New Year everyone!
>>
>> According to my initial mail it's now time to cut branch_9x. However, I'm in the middle of some build and build-script tuning, so it may delay a few days more.
>>
>> I'm also wondering whether it's better to cut both branch_9x and well as branch_9_0 so everyone can continue adding features for 9.1, with the cost of having to do another backport for every fix that is targeted for 9.0. Will it be confusing to treat branch_9x as a feature-frozen release-branch for all of January?
>>
>> Jan
>>
>>> 21. des. 2021 kl. 20:03 skrev David Smiley <dsmiley@apache.org <ma...@apache.org>>:
>>>
>>> Thanks for volunteering to be the RM!
>>>
>>> No comment on the timeline; I'm in denial of the time flying. Log4shell and all that.
>>>
>>> Let's go to Lucene 9.1 and not 9.0. I'm seeing a massive change to lucene-test-framework in 9.1 on it's way that IMO ought to have been done in 9.0. Going right to 9.1 averts issues there for Solr users writing plugins.
>>>
>>> You're right RE blockers -- it's always tough to let go of our ideals/hopes/dreams on what we want 9.0 to be.
>>>
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
>>>
>>> On Tue, Dec 21, 2021 at 10:57 AM Jan Høydahl <jan.asf@cominvent.com <ma...@cominvent.com>> wrote:
>>> Hi,
>>>
>>> Solr's next feature release will be 9.0 (as 8x is in bugfix mode).
>>> Let's not even think about hacking an 8.12 release based on lucene-solr 8x branch. It will be ugly.
>>>
>>> The "Solr 9.0 release blockers" thread <https://lists.apache.org/thread/m7k2gvgxldkns7jqjnw1ghhqx7s3tpl1> was started exactly 2 months ago to try to prepare us. But we're moving slowly. The same happened for Lucene, until the 9.0 release :) So I'll start the train right now...
>>>
>>> I propose the following rough roadmap:
>>>
>>> December: Cut branch_9x next week and enter feature freeze on that branch
>>> January: Remove blockers, prepare build & release machinery, including Docker
>>> February: Cut branch_9_0 and build RC1 - branch_9x is again re-opened for new features
>>>
>>> I volunteer as RM.
>>>
>>> Wrt blockers, we need to be tough on ourselves and ask the question "Is it possible to release 9.0 without this?"..
>>> At the end of January we should have only a few real blockers left, that are all actively in progress.
>>> The delay between branch_9x and branch_9_0 is to avoid having to backport everything twice during the hardening phase.
>>>
>>> Jan
>>>
>>
>
Re: Solr 9.0.0 release in February
Posted by Houston Putman <ho...@gmail.com>.
If we are doing a "feature freeze" for 9.0, then I think we need to cut
branch_9_0. Otherwise there is going to be at least a month of features
slated for 9.1 that only get committed to 10x. There are bound to be
tickets/commits that fall through and don't end up on branch_9x even though
they are supposed to.
In my original comment I mentioned that "unless there is a need for
branch_9x and branch_9_0 to differ". There already is, so let's go ahead
and cut it.
On Tue, Jan 4, 2022 at 3:34 AM Jan Høydahl <ja...@cominvent.com> wrote:
> Agree. Will cut the branch tomorrow or Thursday.
>
> Current list of 9.0 blockers:
> https://issues.apache.org/jira/issues/?filter=12351219
> Please jump in and help with the ones you care for.
>
> PS: I found a bunch of issues assigned to the "9.0" fixVersion, I moved
> them all to "main (9.0)" which is the correct version to use for 9.0.
>
> Jan
>
> 3. jan. 2022 kl. 20:08 skrev David Smiley <ds...@apache.org>:
>
> I completely agree with Houston; let's not create branch_9_0 yet.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Mon, Jan 3, 2022 at 11:36 AM Houston Putman <ho...@gmail.com>
> wrote:
>
>> I think its fine to start with just branch_9x until we are ready to
>> actually do the release, even if it is unconventional for our processes.
>> There’s no need to have a branch_9_0 until there are actual reasons that
>> 9x and 9_0 would differ (i.e. 9.0.0 is ready to be released and people want
>> to add things for 9.1.0).
>>
>> On Mon, Jan 3, 2022 at 10:31 AM Jan Høydahl <ja...@cominvent.com>
>> wrote:
>>
>>> Happy New Year everyone!
>>>
>>> According to my initial mail it's now time to cut branch_9x. However,
>>> I'm in the middle of some build and build-script tuning, so it may delay a
>>> few days more.
>>>
>>> I'm also wondering whether it's better to cut both branch_9x and well as
>>> branch_9_0 so everyone can continue adding features for 9.1, with the cost
>>> of having to do another backport for every fix that is targeted for 9.0.
>>> Will it be confusing to treat branch_9x as a feature-frozen release-branch
>>> for all of January?
>>>
>>> Jan
>>>
>>> 21. des. 2021 kl. 20:03 skrev David Smiley <ds...@apache.org>:
>>>
>>> Thanks for volunteering to be the RM!
>>>
>>> No comment on the timeline; I'm in denial of the time flying. Log4shell
>>> and all that.
>>>
>>> Let's go to Lucene 9.1 and not 9.0. I'm seeing a massive change to
>>> lucene-test-framework in 9.1 on it's way that IMO ought to have been done
>>> in 9.0. Going right to 9.1 averts issues there for Solr users writing
>>> plugins.
>>>
>>> You're right RE blockers -- it's always tough to let go of our
>>> ideals/hopes/dreams on what we want 9.0 to be.
>>>
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley
>>>
>>>
>>> On Tue, Dec 21, 2021 at 10:57 AM Jan Høydahl <ja...@cominvent.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Solr's next feature release will be 9.0 (as 8x is in bugfix mode).
>>>> Let's not even think about hacking an 8.12 release based on lucene-solr
>>>> 8x branch. It will be ugly.
>>>>
>>>> The "Solr 9.0 release blockers" thread
>>>> <https://lists.apache.org/thread/m7k2gvgxldkns7jqjnw1ghhqx7s3tpl1> was
>>>> started exactly 2 months ago to try to prepare us. But we're moving slowly.
>>>> The same happened for Lucene, until the 9.0 release :) So I'll start the
>>>> train right now...
>>>>
>>>> I propose the following rough roadmap:
>>>>
>>>>
>>>> - *December*: Cut branch_9x next week and enter feature freeze on
>>>> that branch
>>>> - *January*: Remove blockers, prepare build & release machinery,
>>>> including Docker
>>>> - *February*: Cut branch_9_0 and build RC1 - branch_9x is again
>>>> re-opened for new features
>>>>
>>>>
>>>> I volunteer as RM.
>>>>
>>>> Wrt blockers, we need to be tough on ourselves and ask the question "Is
>>>> it possible to release 9.0 without this?"..
>>>> At the end of January we should have only a few real blockers left,
>>>> that are all actively in progress.
>>>> The delay between branch_9x and branch_9_0 is to avoid having to
>>>> backport everything twice during the hardening phase.
>>>>
>>>> Jan
>>>>
>>>>
>>>
>
Re: Solr 9.0.0 release in February
Posted by Jan Høydahl <ja...@cominvent.com>.
Agree. Will cut the branch tomorrow or Thursday.
Current list of 9.0 blockers: https://issues.apache.org/jira/issues/?filter=12351219
Please jump in and help with the ones you care for.
PS: I found a bunch of issues assigned to the "9.0" fixVersion, I moved them all to "main (9.0)" which is the correct version to use for 9.0.
Jan
> 3. jan. 2022 kl. 20:08 skrev David Smiley <ds...@apache.org>:
>
> I completely agree with Houston; let's not create branch_9_0 yet.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
>
> On Mon, Jan 3, 2022 at 11:36 AM Houston Putman <houstonputman@gmail.com <ma...@gmail.com>> wrote:
> I think its fine to start with just branch_9x until we are ready to actually do the release, even if it is unconventional for our processes. There’s no need to have a branch_9_0 until there are actual reasons that 9x and 9_0 would differ (i.e. 9.0.0 is ready to be released and people want to add things for 9.1.0).
>
> On Mon, Jan 3, 2022 at 10:31 AM Jan Høydahl <jan.asf@cominvent.com <ma...@cominvent.com>> wrote:
> Happy New Year everyone!
>
> According to my initial mail it's now time to cut branch_9x. However, I'm in the middle of some build and build-script tuning, so it may delay a few days more.
>
> I'm also wondering whether it's better to cut both branch_9x and well as branch_9_0 so everyone can continue adding features for 9.1, with the cost of having to do another backport for every fix that is targeted for 9.0. Will it be confusing to treat branch_9x as a feature-frozen release-branch for all of January?
>
> Jan
>
>> 21. des. 2021 kl. 20:03 skrev David Smiley <dsmiley@apache.org <ma...@apache.org>>:
>>
>> Thanks for volunteering to be the RM!
>>
>> No comment on the timeline; I'm in denial of the time flying. Log4shell and all that.
>>
>> Let's go to Lucene 9.1 and not 9.0. I'm seeing a massive change to lucene-test-framework in 9.1 on it's way that IMO ought to have been done in 9.0. Going right to 9.1 averts issues there for Solr users writing plugins.
>>
>> You're right RE blockers -- it's always tough to let go of our ideals/hopes/dreams on what we want 9.0 to be.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
>>
>> On Tue, Dec 21, 2021 at 10:57 AM Jan Høydahl <jan.asf@cominvent.com <ma...@cominvent.com>> wrote:
>> Hi,
>>
>> Solr's next feature release will be 9.0 (as 8x is in bugfix mode).
>> Let's not even think about hacking an 8.12 release based on lucene-solr 8x branch. It will be ugly.
>>
>> The "Solr 9.0 release blockers" thread <https://lists.apache.org/thread/m7k2gvgxldkns7jqjnw1ghhqx7s3tpl1> was started exactly 2 months ago to try to prepare us. But we're moving slowly. The same happened for Lucene, until the 9.0 release :) So I'll start the train right now...
>>
>> I propose the following rough roadmap:
>>
>> December: Cut branch_9x next week and enter feature freeze on that branch
>> January: Remove blockers, prepare build & release machinery, including Docker
>> February: Cut branch_9_0 and build RC1 - branch_9x is again re-opened for new features
>>
>> I volunteer as RM.
>>
>> Wrt blockers, we need to be tough on ourselves and ask the question "Is it possible to release 9.0 without this?"..
>> At the end of January we should have only a few real blockers left, that are all actively in progress.
>> The delay between branch_9x and branch_9_0 is to avoid having to backport everything twice during the hardening phase.
>>
>> Jan
>>
>
Re: Solr 9.0.0 release in February
Posted by David Smiley <ds...@apache.org>.
I completely agree with Houston; let's not create branch_9_0 yet.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Mon, Jan 3, 2022 at 11:36 AM Houston Putman <ho...@gmail.com>
wrote:
> I think its fine to start with just branch_9x until we are ready to
> actually do the release, even if it is unconventional for our processes.
> There’s no need to have a branch_9_0 until there are actual reasons that
> 9x and 9_0 would differ (i.e. 9.0.0 is ready to be released and people want
> to add things for 9.1.0).
>
> On Mon, Jan 3, 2022 at 10:31 AM Jan Høydahl <ja...@cominvent.com> wrote:
>
>> Happy New Year everyone!
>>
>> According to my initial mail it's now time to cut branch_9x. However, I'm
>> in the middle of some build and build-script tuning, so it may delay a few
>> days more.
>>
>> I'm also wondering whether it's better to cut both branch_9x and well as
>> branch_9_0 so everyone can continue adding features for 9.1, with the cost
>> of having to do another backport for every fix that is targeted for 9.0.
>> Will it be confusing to treat branch_9x as a feature-frozen release-branch
>> for all of January?
>>
>> Jan
>>
>> 21. des. 2021 kl. 20:03 skrev David Smiley <ds...@apache.org>:
>>
>> Thanks for volunteering to be the RM!
>>
>> No comment on the timeline; I'm in denial of the time flying. Log4shell
>> and all that.
>>
>> Let's go to Lucene 9.1 and not 9.0. I'm seeing a massive change to
>> lucene-test-framework in 9.1 on it's way that IMO ought to have been done
>> in 9.0. Going right to 9.1 averts issues there for Solr users writing
>> plugins.
>>
>> You're right RE blockers -- it's always tough to let go of our
>> ideals/hopes/dreams on what we want 9.0 to be.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Tue, Dec 21, 2021 at 10:57 AM Jan Høydahl <ja...@cominvent.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Solr's next feature release will be 9.0 (as 8x is in bugfix mode).
>>> Let's not even think about hacking an 8.12 release based on lucene-solr
>>> 8x branch. It will be ugly.
>>>
>>> The "Solr 9.0 release blockers" thread
>>> <https://lists.apache.org/thread/m7k2gvgxldkns7jqjnw1ghhqx7s3tpl1> was
>>> started exactly 2 months ago to try to prepare us. But we're moving slowly.
>>> The same happened for Lucene, until the 9.0 release :) So I'll start the
>>> train right now...
>>>
>>> I propose the following rough roadmap:
>>>
>>>
>>> - *December*: Cut branch_9x next week and enter feature freeze on
>>> that branch
>>> - *January*: Remove blockers, prepare build & release machinery,
>>> including Docker
>>> - *February*: Cut branch_9_0 and build RC1 - branch_9x is again
>>> re-opened for new features
>>>
>>>
>>> I volunteer as RM.
>>>
>>> Wrt blockers, we need to be tough on ourselves and ask the question "Is
>>> it possible to release 9.0 without this?"..
>>> At the end of January we should have only a few real blockers left, that
>>> are all actively in progress.
>>> The delay between branch_9x and branch_9_0 is to avoid having to
>>> backport everything twice during the hardening phase.
>>>
>>> Jan
>>>
>>>
>>
Re: Solr 9.0.0 release in February
Posted by Houston Putman <ho...@gmail.com>.
I think its fine to start with just branch_9x until we are ready to
actually do the release, even if it is unconventional for our processes.
There’s no need to have a branch_9_0 until there are actual reasons that
9x and 9_0 would differ (i.e. 9.0.0 is ready to be released and people want
to add things for 9.1.0).
On Mon, Jan 3, 2022 at 10:31 AM Jan Høydahl <ja...@cominvent.com> wrote:
> Happy New Year everyone!
>
> According to my initial mail it's now time to cut branch_9x. However, I'm
> in the middle of some build and build-script tuning, so it may delay a few
> days more.
>
> I'm also wondering whether it's better to cut both branch_9x and well as
> branch_9_0 so everyone can continue adding features for 9.1, with the cost
> of having to do another backport for every fix that is targeted for 9.0.
> Will it be confusing to treat branch_9x as a feature-frozen release-branch
> for all of January?
>
> Jan
>
> 21. des. 2021 kl. 20:03 skrev David Smiley <ds...@apache.org>:
>
> Thanks for volunteering to be the RM!
>
> No comment on the timeline; I'm in denial of the time flying. Log4shell
> and all that.
>
> Let's go to Lucene 9.1 and not 9.0. I'm seeing a massive change to
> lucene-test-framework in 9.1 on it's way that IMO ought to have been done
> in 9.0. Going right to 9.1 averts issues there for Solr users writing
> plugins.
>
> You're right RE blockers -- it's always tough to let go of our
> ideals/hopes/dreams on what we want 9.0 to be.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Tue, Dec 21, 2021 at 10:57 AM Jan Høydahl <ja...@cominvent.com>
> wrote:
>
>> Hi,
>>
>> Solr's next feature release will be 9.0 (as 8x is in bugfix mode).
>> Let's not even think about hacking an 8.12 release based on lucene-solr
>> 8x branch. It will be ugly.
>>
>> The "Solr 9.0 release blockers" thread
>> <https://lists.apache.org/thread/m7k2gvgxldkns7jqjnw1ghhqx7s3tpl1> was
>> started exactly 2 months ago to try to prepare us. But we're moving slowly.
>> The same happened for Lucene, until the 9.0 release :) So I'll start the
>> train right now...
>>
>> I propose the following rough roadmap:
>>
>>
>> - *December*: Cut branch_9x next week and enter feature freeze on
>> that branch
>> - *January*: Remove blockers, prepare build & release machinery,
>> including Docker
>> - *February*: Cut branch_9_0 and build RC1 - branch_9x is again
>> re-opened for new features
>>
>>
>> I volunteer as RM.
>>
>> Wrt blockers, we need to be tough on ourselves and ask the question "Is
>> it possible to release 9.0 without this?"..
>> At the end of January we should have only a few real blockers left, that
>> are all actively in progress.
>> The delay between branch_9x and branch_9_0 is to avoid having to backport
>> everything twice during the hardening phase.
>>
>> Jan
>>
>>
>
Re: Solr 9.0.0 release in February
Posted by Jan Høydahl <ja...@cominvent.com>.
Happy New Year everyone!
According to my initial mail it's now time to cut branch_9x. However, I'm in the middle of some build and build-script tuning, so it may delay a few days more.
I'm also wondering whether it's better to cut both branch_9x and well as branch_9_0 so everyone can continue adding features for 9.1, with the cost of having to do another backport for every fix that is targeted for 9.0. Will it be confusing to treat branch_9x as a feature-frozen release-branch for all of January?
Jan
> 21. des. 2021 kl. 20:03 skrev David Smiley <ds...@apache.org>:
>
> Thanks for volunteering to be the RM!
>
> No comment on the timeline; I'm in denial of the time flying. Log4shell and all that.
>
> Let's go to Lucene 9.1 and not 9.0. I'm seeing a massive change to lucene-test-framework in 9.1 on it's way that IMO ought to have been done in 9.0. Going right to 9.1 averts issues there for Solr users writing plugins.
>
> You're right RE blockers -- it's always tough to let go of our ideals/hopes/dreams on what we want 9.0 to be.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
>
> On Tue, Dec 21, 2021 at 10:57 AM Jan Høydahl <jan.asf@cominvent.com <ma...@cominvent.com>> wrote:
> Hi,
>
> Solr's next feature release will be 9.0 (as 8x is in bugfix mode).
> Let's not even think about hacking an 8.12 release based on lucene-solr 8x branch. It will be ugly.
>
> The "Solr 9.0 release blockers" thread <https://lists.apache.org/thread/m7k2gvgxldkns7jqjnw1ghhqx7s3tpl1> was started exactly 2 months ago to try to prepare us. But we're moving slowly. The same happened for Lucene, until the 9.0 release :) So I'll start the train right now...
>
> I propose the following rough roadmap:
>
> December: Cut branch_9x next week and enter feature freeze on that branch
> January: Remove blockers, prepare build & release machinery, including Docker
> February: Cut branch_9_0 and build RC1 - branch_9x is again re-opened for new features
>
> I volunteer as RM.
>
> Wrt blockers, we need to be tough on ourselves and ask the question "Is it possible to release 9.0 without this?"..
> At the end of January we should have only a few real blockers left, that are all actively in progress.
> The delay between branch_9x and branch_9_0 is to avoid having to backport everything twice during the hardening phase.
>
> Jan
>
Re: Solr 9.0.0 release in February
Posted by David Smiley <ds...@apache.org>.
Thanks for volunteering to be the RM!
No comment on the timeline; I'm in denial of the time flying. Log4shell
and all that.
Let's go to Lucene 9.1 and not 9.0. I'm seeing a massive change to
lucene-test-framework in 9.1 on it's way that IMO ought to have been done
in 9.0. Going right to 9.1 averts issues there for Solr users writing
plugins.
You're right RE blockers -- it's always tough to let go of our
ideals/hopes/dreams on what we want 9.0 to be.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Dec 21, 2021 at 10:57 AM Jan Høydahl <ja...@cominvent.com> wrote:
> Hi,
>
> Solr's next feature release will be 9.0 (as 8x is in bugfix mode).
> Let's not even think about hacking an 8.12 release based on lucene-solr 8x
> branch. It will be ugly.
>
> The "Solr 9.0 release blockers" thread
> <https://lists.apache.org/thread/m7k2gvgxldkns7jqjnw1ghhqx7s3tpl1> was
> started exactly 2 months ago to try to prepare us. But we're moving slowly.
> The same happened for Lucene, until the 9.0 release :) So I'll start the
> train right now...
>
> I propose the following rough roadmap:
>
>
> - *December*: Cut branch_9x next week and enter feature freeze on that
> branch
> - *January*: Remove blockers, prepare build & release machinery,
> including Docker
> - *February*: Cut branch_9_0 and build RC1 - branch_9x is again
> re-opened for new features
>
>
> I volunteer as RM.
>
> Wrt blockers, we need to be tough on ourselves and ask the question "Is it
> possible to release 9.0 without this?"..
> At the end of January we should have only a few real blockers left, that
> are all actively in progress.
> The delay between branch_9x and branch_9_0 is to avoid having to backport
> everything twice during the hardening phase.
>
> Jan
>
>