You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by Paul Irwin <pa...@gmail.com> on 2025/08/27 03:19:44 UTC
[VOTE] New Lucene.NET Extensions Repository/Prefix (GSoC 2025)
I would like to propose for approval a new Apache repository (named
`lucenenet-extensions`) and name prefix for future Lucene.NET Extensions
NuGet packages, the details of which are below. This email starts a 72-hour
approval vote for PMC members.
As you probably know, I have been working this summer with Nehan Khan
Pathan as the mentor for his Google Summer of Code 2025 project. This
project involved improving our Replicator support for ASP.NET Core, as well
as the Dependency Injection (DI) registration of common Lucene.NET Services
via Microsoft.Extensions.DependencyInjection (MEDI). By all measures, this
project has been a great success! Congratulations to Nehan for getting to
the finish line as we finish up the project this week. Once we're on the
other side of the final submission, I'll post a more detailed update to
this dev list.
The result of this work is a collection of "Extension" libraries to
Lucene.NET, as we're calling them. These are named to mirror the use of
"Extensions" in "Microsoft.Extensions.Logging" and
"Microsoft.Extensions.DependencyInjection." You can see the work in
progress at a repo on my GitHub, where we have been integrating his work in
preparation for eventually moving this into an official Apache repo for our
project: https://github.com/paulirwin/lucenenet-extensions
Please note that the work there is incomplete (some is still going through
review in a PR), does not yet have proper license setup, minimal and likely
inadequate CI, no versioning or NuGet details, etc. Nehan and I are
actively working on moving his prototype code into near-final form in this
repo as I write this. This vote is NOT intended to be a reflection on
whether or not this code is good to merge into a new repo nor publish to
NuGet. I only provide the link here so that you can view the code and
project structure if you are interested, to get an idea of what Nehan did
for this project.
At first, we will have these Extensions available, but may add others as
demand and community contributions dictate:
- Lucene.Net.Extensions.DependencyInjection - core MEDI extension
methods to aid in registering index readers, writers, searchers, etc. in
modern .NET applications
- Lucene.Net.Extensions.AspNetCore.Replicator - ASP.NET Core 8+ support
for index replication
- Lucene.Net.Extensions.SelfHost.Replicator - .NET BackgroundService
support for hosting a Lucene.NET replication server (uses ASP.NET Core
Kestrel under the hood as an implementation detail, but is designed to be
used in non-ASP.NET Core applications such as Windows/Linux services)
So, why not merge this into the main Lucene.NET repo? Well, these are
intended to track modern and rapidly-evolving versions of the underlying
dependencies (i.e. Microsoft.Extensions.DependencyInjection, ASP.NET Core)
and we need to be able to update those out-of-band of a Lucene.NET release.
Also, we would like the flexibility to launch new extensions projects in
the future without having to also do a Lucene.NET release or tie it to the
Lucene.NET versioning.
At the start of this project, I worked with Shad to come up with the
direction for the package names. We will welcome any feedback on the
individual package names (or any other feedback you have) once the code is
PRed for introduction into this new repo. We just want to have an
established repository name and corresponding namespace and package prefix
before we begin.
As far as the repo name goes, Apache sub-repos for our project must start
with `lucenenet-`, so that part is non-negotiable. I figured
`lucenenet-extensions` is simple, memorable, and concisely describes the
contents.
Given that these packages are intended to be consumed by the public on
NuGet once released, the release of these packages will go through the
normal Apache release vote and process (unlike the previous vote for the
exception for the internal-use code analysis packages). But releasing these
is not up for vote at this time.
Now that you can see what this project was all about, here's what I'm
asking for a vote on:
- Approval to set up a new `lucenenet-extensions` Apache repo, much like
we did recently for `lucenenet-codeanalysis-dev` (including approval of the
repo name)
- Approval of the *name* *only* of the Lucene.Net.Extensions.*
package/namespace prefix
This vote does NOT approve the release of any packages or artifacts: this
is NOT a release vote.
Only votes from the PMC are binding, but everyone is welcome to vote.
Please reply with your +1 or -1 vote, with or without any comments.
The vote passes if at least three binding +1 votes are cast.
Thank you,
Paul Irwin
Lucene.NET PMC Member
Apache Software Foundation Member
Re: [VOTE] New Lucene.NET Extensions Repository/Prefix (GSoC 2025)
Posted by Paul Irwin <pa...@gmail.com>.
The lucenenet-extensions repo has been created, and is currently empty. The
code will live at https://github.com/apache/lucenenet-extensions
Thanks,
Paul Irwin
On Sat, Aug 30, 2025 at 8:44 AM Paul Irwin <pa...@gmail.com> wrote:
> Thank you all for participating in the vote. The vote passes with 5
> binding +1 votes including my own. I will work on setting up the repo and
> will provide a final GSoC update once we have the PR ready!
>
> Paul Irwin
>
>
> On Fri, Aug 29, 2025 at 1:02 PM Elad Margalit <el...@gmail.com> wrote:
>
>> +1
>>
>> On Thu, Aug 28, 2025 at 6:32 PM <Ro...@giftoasis.com> wrote:
>>
>> > +1 Makes sense to me.
>> >
>> > -----Original Message-----
>> > From: Shannon Deminick <sd...@gmail.com>
>> > Sent: Wednesday, August 27, 2025 8:23 PM
>> > To: dev@lucenenet.apache.org
>> > Subject: Re: [VOTE] New Lucene.NET Extensions Repository/Prefix (GSoC
>> 2025)
>> >
>> > +1
>> >
>> > Sounds fine to me
>> >
>> >
>> > On Tue, 26 Aug 2025 at 21:20, Paul Irwin <pa...@gmail.com> wrote:
>> >
>> > > I would like to propose for approval a new Apache repository (named
>> > > `lucenenet-extensions`) and name prefix for future Lucene.NET
>> > > Extensions NuGet packages, the details of which are below. This email
>> > > starts a 72-hour approval vote for PMC members.
>> > >
>> > > As you probably know, I have been working this summer with Nehan Khan
>> > > Pathan as the mentor for his Google Summer of Code 2025 project. This
>> > > project involved improving our Replicator support for ASP.NET Core,
>> as
>> > > well as the Dependency Injection (DI) registration of common
>> > > Lucene.NET Services via Microsoft.Extensions.DependencyInjection
>> > > (MEDI). By all measures, this project has been a great success!
>> > > Congratulations to Nehan for getting to the finish line as we finish
>> > > up the project this week. Once we're on the other side of the final
>> > > submission, I'll post a more detailed update to this dev list.
>> > >
>> > > The result of this work is a collection of "Extension" libraries to
>> > > Lucene.NET, as we're calling them. These are named to mirror the use
>> > > of "Extensions" in "Microsoft.Extensions.Logging" and
>> > > "Microsoft.Extensions.DependencyInjection." You can see the work in
>> > > progress at a repo on my GitHub, where we have been integrating his
>> > > work in preparation for eventually moving this into an official Apache
>> > > repo for our
>> > > project: https://github.com/paulirwin/lucenenet-extensions
>> > >
>> > > Please note that the work there is incomplete (some is still going
>> > > through review in a PR), does not yet have proper license setup,
>> > > minimal and likely inadequate CI, no versioning or NuGet details, etc.
>> > > Nehan and I are actively working on moving his prototype code into
>> > > near-final form in this repo as I write this. This vote is NOT
>> > > intended to be a reflection on whether or not this code is good to
>> > > merge into a new repo nor publish to NuGet. I only provide the link
>> > > here so that you can view the code and project structure if you are
>> > > interested, to get an idea of what Nehan did for this project.
>> > >
>> > > At first, we will have these Extensions available, but may add others
>> > > as demand and community contributions dictate:
>> > >
>> > > - Lucene.Net.Extensions.DependencyInjection - core MEDI extension
>> > > methods to aid in registering index readers, writers, searchers,
>> etc.
>> > in
>> > > modern .NET applications
>> > > - Lucene.Net.Extensions.AspNetCore.Replicator - ASP.NET Core 8+
>> > support
>> > > for index replication
>> > > - Lucene.Net.Extensions.SelfHost.Replicator - .NET
>> BackgroundService
>> > > support for hosting a Lucene.NET replication server (uses ASP.NET
>> > Core
>> > > Kestrel under the hood as an implementation detail, but is designed
>> > > to be
>> > > used in non-ASP.NET Core applications such as Windows/Linux
>> > > services)
>> > >
>> > > So, why not merge this into the main Lucene.NET repo? Well, these are
>> > > intended to track modern and rapidly-evolving versions of the
>> > > underlying dependencies (i.e.
>> > > Microsoft.Extensions.DependencyInjection, ASP.NET Core) and we need
>> to
>> > be able to update those out-of-band of a Lucene.NET release.
>> > > Also, we would like the flexibility to launch new extensions projects
>> > > in the future without having to also do a Lucene.NET release or tie it
>> > > to the Lucene.NET versioning.
>> > >
>> > > At the start of this project, I worked with Shad to come up with the
>> > > direction for the package names. We will welcome any feedback on the
>> > > individual package names (or any other feedback you have) once the
>> > > code is PRed for introduction into this new repo. We just want to have
>> > > an established repository name and corresponding namespace and package
>> > > prefix before we begin.
>> > >
>> > > As far as the repo name goes, Apache sub-repos for our project must
>> > > start with `lucenenet-`, so that part is non-negotiable. I figured
>> > > `lucenenet-extensions` is simple, memorable, and concisely describes
>> > > the contents.
>> > >
>> > > Given that these packages are intended to be consumed by the public on
>> > > NuGet once released, the release of these packages will go through the
>> > > normal Apache release vote and process (unlike the previous vote for
>> > > the exception for the internal-use code analysis packages). But
>> > > releasing these is not up for vote at this time.
>> > >
>> > > Now that you can see what this project was all about, here's what I'm
>> > > asking for a vote on:
>> > >
>> > > - Approval to set up a new `lucenenet-extensions` Apache repo, much
>> > like
>> > > we did recently for `lucenenet-codeanalysis-dev` (including
>> > > approval of the
>> > > repo name)
>> > > - Approval of the *name* *only* of the Lucene.Net.Extensions.*
>> > > package/namespace prefix
>> > >
>> > > This vote does NOT approve the release of any packages or artifacts:
>> > > this is NOT a release vote.
>> > >
>> > > Only votes from the PMC are binding, but everyone is welcome to vote.
>> > > Please reply with your +1 or -1 vote, with or without any comments.
>> > > The vote passes if at least three binding +1 votes are cast.
>> > >
>> > > Thank you,
>> > >
>> > > Paul Irwin
>> > > Lucene.NET PMC Member
>> > > Apache Software Foundation Member
>> > >
>> >
>> >
>> >
>> >
>>
>
Re: [VOTE] New Lucene.NET Extensions Repository/Prefix (GSoC 2025)
Posted by Paul Irwin <pa...@gmail.com>.
Thank you all for participating in the vote. The vote passes with 5
binding +1 votes including my own. I will work on setting up the repo and
will provide a final GSoC update once we have the PR ready!
Paul Irwin
On Fri, Aug 29, 2025 at 1:02 PM Elad Margalit <el...@gmail.com> wrote:
> +1
>
> On Thu, Aug 28, 2025 at 6:32 PM <Ro...@giftoasis.com> wrote:
>
> > +1 Makes sense to me.
> >
> > -----Original Message-----
> > From: Shannon Deminick <sd...@gmail.com>
> > Sent: Wednesday, August 27, 2025 8:23 PM
> > To: dev@lucenenet.apache.org
> > Subject: Re: [VOTE] New Lucene.NET Extensions Repository/Prefix (GSoC
> 2025)
> >
> > +1
> >
> > Sounds fine to me
> >
> >
> > On Tue, 26 Aug 2025 at 21:20, Paul Irwin <pa...@gmail.com> wrote:
> >
> > > I would like to propose for approval a new Apache repository (named
> > > `lucenenet-extensions`) and name prefix for future Lucene.NET
> > > Extensions NuGet packages, the details of which are below. This email
> > > starts a 72-hour approval vote for PMC members.
> > >
> > > As you probably know, I have been working this summer with Nehan Khan
> > > Pathan as the mentor for his Google Summer of Code 2025 project. This
> > > project involved improving our Replicator support for ASP.NET Core, as
> > > well as the Dependency Injection (DI) registration of common
> > > Lucene.NET Services via Microsoft.Extensions.DependencyInjection
> > > (MEDI). By all measures, this project has been a great success!
> > > Congratulations to Nehan for getting to the finish line as we finish
> > > up the project this week. Once we're on the other side of the final
> > > submission, I'll post a more detailed update to this dev list.
> > >
> > > The result of this work is a collection of "Extension" libraries to
> > > Lucene.NET, as we're calling them. These are named to mirror the use
> > > of "Extensions" in "Microsoft.Extensions.Logging" and
> > > "Microsoft.Extensions.DependencyInjection." You can see the work in
> > > progress at a repo on my GitHub, where we have been integrating his
> > > work in preparation for eventually moving this into an official Apache
> > > repo for our
> > > project: https://github.com/paulirwin/lucenenet-extensions
> > >
> > > Please note that the work there is incomplete (some is still going
> > > through review in a PR), does not yet have proper license setup,
> > > minimal and likely inadequate CI, no versioning or NuGet details, etc.
> > > Nehan and I are actively working on moving his prototype code into
> > > near-final form in this repo as I write this. This vote is NOT
> > > intended to be a reflection on whether or not this code is good to
> > > merge into a new repo nor publish to NuGet. I only provide the link
> > > here so that you can view the code and project structure if you are
> > > interested, to get an idea of what Nehan did for this project.
> > >
> > > At first, we will have these Extensions available, but may add others
> > > as demand and community contributions dictate:
> > >
> > > - Lucene.Net.Extensions.DependencyInjection - core MEDI extension
> > > methods to aid in registering index readers, writers, searchers,
> etc.
> > in
> > > modern .NET applications
> > > - Lucene.Net.Extensions.AspNetCore.Replicator - ASP.NET Core 8+
> > support
> > > for index replication
> > > - Lucene.Net.Extensions.SelfHost.Replicator - .NET BackgroundService
> > > support for hosting a Lucene.NET replication server (uses ASP.NET
> > Core
> > > Kestrel under the hood as an implementation detail, but is designed
> > > to be
> > > used in non-ASP.NET Core applications such as Windows/Linux
> > > services)
> > >
> > > So, why not merge this into the main Lucene.NET repo? Well, these are
> > > intended to track modern and rapidly-evolving versions of the
> > > underlying dependencies (i.e.
> > > Microsoft.Extensions.DependencyInjection, ASP.NET Core) and we need to
> > be able to update those out-of-band of a Lucene.NET release.
> > > Also, we would like the flexibility to launch new extensions projects
> > > in the future without having to also do a Lucene.NET release or tie it
> > > to the Lucene.NET versioning.
> > >
> > > At the start of this project, I worked with Shad to come up with the
> > > direction for the package names. We will welcome any feedback on the
> > > individual package names (or any other feedback you have) once the
> > > code is PRed for introduction into this new repo. We just want to have
> > > an established repository name and corresponding namespace and package
> > > prefix before we begin.
> > >
> > > As far as the repo name goes, Apache sub-repos for our project must
> > > start with `lucenenet-`, so that part is non-negotiable. I figured
> > > `lucenenet-extensions` is simple, memorable, and concisely describes
> > > the contents.
> > >
> > > Given that these packages are intended to be consumed by the public on
> > > NuGet once released, the release of these packages will go through the
> > > normal Apache release vote and process (unlike the previous vote for
> > > the exception for the internal-use code analysis packages). But
> > > releasing these is not up for vote at this time.
> > >
> > > Now that you can see what this project was all about, here's what I'm
> > > asking for a vote on:
> > >
> > > - Approval to set up a new `lucenenet-extensions` Apache repo, much
> > like
> > > we did recently for `lucenenet-codeanalysis-dev` (including
> > > approval of the
> > > repo name)
> > > - Approval of the *name* *only* of the Lucene.Net.Extensions.*
> > > package/namespace prefix
> > >
> > > This vote does NOT approve the release of any packages or artifacts:
> > > this is NOT a release vote.
> > >
> > > Only votes from the PMC are binding, but everyone is welcome to vote.
> > > Please reply with your +1 or -1 vote, with or without any comments.
> > > The vote passes if at least three binding +1 votes are cast.
> > >
> > > Thank you,
> > >
> > > Paul Irwin
> > > Lucene.NET PMC Member
> > > Apache Software Foundation Member
> > >
> >
> >
> >
> >
>
Re: [VOTE] New Lucene.NET Extensions Repository/Prefix (GSoC 2025)
Posted by Elad Margalit <el...@gmail.com>.
+1
On Thu, Aug 28, 2025 at 6:32 PM <Ro...@giftoasis.com> wrote:
> +1 Makes sense to me.
>
> -----Original Message-----
> From: Shannon Deminick <sd...@gmail.com>
> Sent: Wednesday, August 27, 2025 8:23 PM
> To: dev@lucenenet.apache.org
> Subject: Re: [VOTE] New Lucene.NET Extensions Repository/Prefix (GSoC 2025)
>
> +1
>
> Sounds fine to me
>
>
> On Tue, 26 Aug 2025 at 21:20, Paul Irwin <pa...@gmail.com> wrote:
>
> > I would like to propose for approval a new Apache repository (named
> > `lucenenet-extensions`) and name prefix for future Lucene.NET
> > Extensions NuGet packages, the details of which are below. This email
> > starts a 72-hour approval vote for PMC members.
> >
> > As you probably know, I have been working this summer with Nehan Khan
> > Pathan as the mentor for his Google Summer of Code 2025 project. This
> > project involved improving our Replicator support for ASP.NET Core, as
> > well as the Dependency Injection (DI) registration of common
> > Lucene.NET Services via Microsoft.Extensions.DependencyInjection
> > (MEDI). By all measures, this project has been a great success!
> > Congratulations to Nehan for getting to the finish line as we finish
> > up the project this week. Once we're on the other side of the final
> > submission, I'll post a more detailed update to this dev list.
> >
> > The result of this work is a collection of "Extension" libraries to
> > Lucene.NET, as we're calling them. These are named to mirror the use
> > of "Extensions" in "Microsoft.Extensions.Logging" and
> > "Microsoft.Extensions.DependencyInjection." You can see the work in
> > progress at a repo on my GitHub, where we have been integrating his
> > work in preparation for eventually moving this into an official Apache
> > repo for our
> > project: https://github.com/paulirwin/lucenenet-extensions
> >
> > Please note that the work there is incomplete (some is still going
> > through review in a PR), does not yet have proper license setup,
> > minimal and likely inadequate CI, no versioning or NuGet details, etc.
> > Nehan and I are actively working on moving his prototype code into
> > near-final form in this repo as I write this. This vote is NOT
> > intended to be a reflection on whether or not this code is good to
> > merge into a new repo nor publish to NuGet. I only provide the link
> > here so that you can view the code and project structure if you are
> > interested, to get an idea of what Nehan did for this project.
> >
> > At first, we will have these Extensions available, but may add others
> > as demand and community contributions dictate:
> >
> > - Lucene.Net.Extensions.DependencyInjection - core MEDI extension
> > methods to aid in registering index readers, writers, searchers, etc.
> in
> > modern .NET applications
> > - Lucene.Net.Extensions.AspNetCore.Replicator - ASP.NET Core 8+
> support
> > for index replication
> > - Lucene.Net.Extensions.SelfHost.Replicator - .NET BackgroundService
> > support for hosting a Lucene.NET replication server (uses ASP.NET
> Core
> > Kestrel under the hood as an implementation detail, but is designed
> > to be
> > used in non-ASP.NET Core applications such as Windows/Linux
> > services)
> >
> > So, why not merge this into the main Lucene.NET repo? Well, these are
> > intended to track modern and rapidly-evolving versions of the
> > underlying dependencies (i.e.
> > Microsoft.Extensions.DependencyInjection, ASP.NET Core) and we need to
> be able to update those out-of-band of a Lucene.NET release.
> > Also, we would like the flexibility to launch new extensions projects
> > in the future without having to also do a Lucene.NET release or tie it
> > to the Lucene.NET versioning.
> >
> > At the start of this project, I worked with Shad to come up with the
> > direction for the package names. We will welcome any feedback on the
> > individual package names (or any other feedback you have) once the
> > code is PRed for introduction into this new repo. We just want to have
> > an established repository name and corresponding namespace and package
> > prefix before we begin.
> >
> > As far as the repo name goes, Apache sub-repos for our project must
> > start with `lucenenet-`, so that part is non-negotiable. I figured
> > `lucenenet-extensions` is simple, memorable, and concisely describes
> > the contents.
> >
> > Given that these packages are intended to be consumed by the public on
> > NuGet once released, the release of these packages will go through the
> > normal Apache release vote and process (unlike the previous vote for
> > the exception for the internal-use code analysis packages). But
> > releasing these is not up for vote at this time.
> >
> > Now that you can see what this project was all about, here's what I'm
> > asking for a vote on:
> >
> > - Approval to set up a new `lucenenet-extensions` Apache repo, much
> like
> > we did recently for `lucenenet-codeanalysis-dev` (including
> > approval of the
> > repo name)
> > - Approval of the *name* *only* of the Lucene.Net.Extensions.*
> > package/namespace prefix
> >
> > This vote does NOT approve the release of any packages or artifacts:
> > this is NOT a release vote.
> >
> > Only votes from the PMC are binding, but everyone is welcome to vote.
> > Please reply with your +1 or -1 vote, with or without any comments.
> > The vote passes if at least three binding +1 votes are cast.
> >
> > Thank you,
> >
> > Paul Irwin
> > Lucene.NET PMC Member
> > Apache Software Foundation Member
> >
>
>
>
>
RE: [VOTE] New Lucene.NET Extensions Repository/Prefix (GSoC 2025)
Posted by Ro...@giftoasis.com.
+1 Makes sense to me.
-----Original Message-----
From: Shannon Deminick <sd...@gmail.com>
Sent: Wednesday, August 27, 2025 8:23 PM
To: dev@lucenenet.apache.org
Subject: Re: [VOTE] New Lucene.NET Extensions Repository/Prefix (GSoC 2025)
+1
Sounds fine to me
On Tue, 26 Aug 2025 at 21:20, Paul Irwin <pa...@gmail.com> wrote:
> I would like to propose for approval a new Apache repository (named
> `lucenenet-extensions`) and name prefix for future Lucene.NET
> Extensions NuGet packages, the details of which are below. This email
> starts a 72-hour approval vote for PMC members.
>
> As you probably know, I have been working this summer with Nehan Khan
> Pathan as the mentor for his Google Summer of Code 2025 project. This
> project involved improving our Replicator support for ASP.NET Core, as
> well as the Dependency Injection (DI) registration of common
> Lucene.NET Services via Microsoft.Extensions.DependencyInjection
> (MEDI). By all measures, this project has been a great success!
> Congratulations to Nehan for getting to the finish line as we finish
> up the project this week. Once we're on the other side of the final
> submission, I'll post a more detailed update to this dev list.
>
> The result of this work is a collection of "Extension" libraries to
> Lucene.NET, as we're calling them. These are named to mirror the use
> of "Extensions" in "Microsoft.Extensions.Logging" and
> "Microsoft.Extensions.DependencyInjection." You can see the work in
> progress at a repo on my GitHub, where we have been integrating his
> work in preparation for eventually moving this into an official Apache
> repo for our
> project: https://github.com/paulirwin/lucenenet-extensions
>
> Please note that the work there is incomplete (some is still going
> through review in a PR), does not yet have proper license setup,
> minimal and likely inadequate CI, no versioning or NuGet details, etc.
> Nehan and I are actively working on moving his prototype code into
> near-final form in this repo as I write this. This vote is NOT
> intended to be a reflection on whether or not this code is good to
> merge into a new repo nor publish to NuGet. I only provide the link
> here so that you can view the code and project structure if you are
> interested, to get an idea of what Nehan did for this project.
>
> At first, we will have these Extensions available, but may add others
> as demand and community contributions dictate:
>
> - Lucene.Net.Extensions.DependencyInjection - core MEDI extension
> methods to aid in registering index readers, writers, searchers, etc. in
> modern .NET applications
> - Lucene.Net.Extensions.AspNetCore.Replicator - ASP.NET Core 8+ support
> for index replication
> - Lucene.Net.Extensions.SelfHost.Replicator - .NET BackgroundService
> support for hosting a Lucene.NET replication server (uses ASP.NET Core
> Kestrel under the hood as an implementation detail, but is designed
> to be
> used in non-ASP.NET Core applications such as Windows/Linux
> services)
>
> So, why not merge this into the main Lucene.NET repo? Well, these are
> intended to track modern and rapidly-evolving versions of the
> underlying dependencies (i.e.
> Microsoft.Extensions.DependencyInjection, ASP.NET Core) and we need to be able to update those out-of-band of a Lucene.NET release.
> Also, we would like the flexibility to launch new extensions projects
> in the future without having to also do a Lucene.NET release or tie it
> to the Lucene.NET versioning.
>
> At the start of this project, I worked with Shad to come up with the
> direction for the package names. We will welcome any feedback on the
> individual package names (or any other feedback you have) once the
> code is PRed for introduction into this new repo. We just want to have
> an established repository name and corresponding namespace and package
> prefix before we begin.
>
> As far as the repo name goes, Apache sub-repos for our project must
> start with `lucenenet-`, so that part is non-negotiable. I figured
> `lucenenet-extensions` is simple, memorable, and concisely describes
> the contents.
>
> Given that these packages are intended to be consumed by the public on
> NuGet once released, the release of these packages will go through the
> normal Apache release vote and process (unlike the previous vote for
> the exception for the internal-use code analysis packages). But
> releasing these is not up for vote at this time.
>
> Now that you can see what this project was all about, here's what I'm
> asking for a vote on:
>
> - Approval to set up a new `lucenenet-extensions` Apache repo, much like
> we did recently for `lucenenet-codeanalysis-dev` (including
> approval of the
> repo name)
> - Approval of the *name* *only* of the Lucene.Net.Extensions.*
> package/namespace prefix
>
> This vote does NOT approve the release of any packages or artifacts:
> this is NOT a release vote.
>
> Only votes from the PMC are binding, but everyone is welcome to vote.
> Please reply with your +1 or -1 vote, with or without any comments.
> The vote passes if at least three binding +1 votes are cast.
>
> Thank you,
>
> Paul Irwin
> Lucene.NET PMC Member
> Apache Software Foundation Member
>
RE: [VOTE] New Lucene.NET Extensions Repository/Prefix (GSoC 2025)
Posted by Shad Storhaug <sh...@shadstorhaug.com>.
+1
-----Original Message-----
From: Shannon Deminick <sd...@gmail.com>
Sent: Thursday, August 28, 2025 7:23 AM
To: dev@lucenenet.apache.org
Subject: Re: [VOTE] New Lucene.NET Extensions Repository/Prefix (GSoC 2025)
+1
Sounds fine to me
On Tue, 26 Aug 2025 at 21:20, Paul Irwin <pa...@gmail.com> wrote:
> I would like to propose for approval a new Apache repository (named
> `lucenenet-extensions`) and name prefix for future Lucene.NET
> Extensions NuGet packages, the details of which are below. This email
> starts a 72-hour approval vote for PMC members.
>
> As you probably know, I have been working this summer with Nehan Khan
> Pathan as the mentor for his Google Summer of Code 2025 project. This
> project involved improving our Replicator support for ASP.NET Core, as
> well as the Dependency Injection (DI) registration of common
> Lucene.NET Services via Microsoft.Extensions.DependencyInjection
> (MEDI). By all measures, this project has been a great success!
> Congratulations to Nehan for getting to the finish line as we finish
> up the project this week. Once we're on the other side of the final
> submission, I'll post a more detailed update to this dev list.
>
> The result of this work is a collection of "Extension" libraries to
> Lucene.NET, as we're calling them. These are named to mirror the use
> of "Extensions" in "Microsoft.Extensions.Logging" and
> "Microsoft.Extensions.DependencyInjection." You can see the work in
> progress at a repo on my GitHub, where we have been integrating his
> work in preparation for eventually moving this into an official Apache
> repo for our
> project: https://github.com/paulirwin/lucenenet-extensions
>
> Please note that the work there is incomplete (some is still going
> through review in a PR), does not yet have proper license setup,
> minimal and likely inadequate CI, no versioning or NuGet details, etc.
> Nehan and I are actively working on moving his prototype code into
> near-final form in this repo as I write this. This vote is NOT
> intended to be a reflection on whether or not this code is good to
> merge into a new repo nor publish to NuGet. I only provide the link
> here so that you can view the code and project structure if you are
> interested, to get an idea of what Nehan did for this project.
>
> At first, we will have these Extensions available, but may add others
> as demand and community contributions dictate:
>
> - Lucene.Net.Extensions.DependencyInjection - core MEDI extension
> methods to aid in registering index readers, writers, searchers, etc. in
> modern .NET applications
> - Lucene.Net.Extensions.AspNetCore.Replicator - ASP.NET Core 8+ support
> for index replication
> - Lucene.Net.Extensions.SelfHost.Replicator - .NET BackgroundService
> support for hosting a Lucene.NET replication server (uses ASP.NET Core
> Kestrel under the hood as an implementation detail, but is designed
> to be
> used in non-ASP.NET Core applications such as Windows/Linux
> services)
>
> So, why not merge this into the main Lucene.NET repo? Well, these are
> intended to track modern and rapidly-evolving versions of the
> underlying dependencies (i.e.
> Microsoft.Extensions.DependencyInjection, ASP.NET Core) and we need to be able to update those out-of-band of a Lucene.NET release.
> Also, we would like the flexibility to launch new extensions projects
> in the future without having to also do a Lucene.NET release or tie it
> to the Lucene.NET versioning.
>
> At the start of this project, I worked with Shad to come up with the
> direction for the package names. We will welcome any feedback on the
> individual package names (or any other feedback you have) once the
> code is PRed for introduction into this new repo. We just want to have
> an established repository name and corresponding namespace and package
> prefix before we begin.
>
> As far as the repo name goes, Apache sub-repos for our project must
> start with `lucenenet-`, so that part is non-negotiable. I figured
> `lucenenet-extensions` is simple, memorable, and concisely describes
> the contents.
>
> Given that these packages are intended to be consumed by the public on
> NuGet once released, the release of these packages will go through the
> normal Apache release vote and process (unlike the previous vote for
> the exception for the internal-use code analysis packages). But
> releasing these is not up for vote at this time.
>
> Now that you can see what this project was all about, here's what I'm
> asking for a vote on:
>
> - Approval to set up a new `lucenenet-extensions` Apache repo, much like
> we did recently for `lucenenet-codeanalysis-dev` (including
> approval of the
> repo name)
> - Approval of the *name* *only* of the Lucene.Net.Extensions.*
> package/namespace prefix
>
> This vote does NOT approve the release of any packages or artifacts:
> this is NOT a release vote.
>
> Only votes from the PMC are binding, but everyone is welcome to vote.
> Please reply with your +1 or -1 vote, with or without any comments.
> The vote passes if at least three binding +1 votes are cast.
>
> Thank you,
>
> Paul Irwin
> Lucene.NET PMC Member
> Apache Software Foundation Member
>
Re: [VOTE] New Lucene.NET Extensions Repository/Prefix (GSoC 2025)
Posted by Shannon Deminick <sd...@gmail.com>.
+1
Sounds fine to me
On Tue, 26 Aug 2025 at 21:20, Paul Irwin <pa...@gmail.com> wrote:
> I would like to propose for approval a new Apache repository (named
> `lucenenet-extensions`) and name prefix for future Lucene.NET Extensions
> NuGet packages, the details of which are below. This email starts a 72-hour
> approval vote for PMC members.
>
> As you probably know, I have been working this summer with Nehan Khan
> Pathan as the mentor for his Google Summer of Code 2025 project. This
> project involved improving our Replicator support for ASP.NET Core, as
> well
> as the Dependency Injection (DI) registration of common Lucene.NET Services
> via Microsoft.Extensions.DependencyInjection (MEDI). By all measures, this
> project has been a great success! Congratulations to Nehan for getting to
> the finish line as we finish up the project this week. Once we're on the
> other side of the final submission, I'll post a more detailed update to
> this dev list.
>
> The result of this work is a collection of "Extension" libraries to
> Lucene.NET, as we're calling them. These are named to mirror the use of
> "Extensions" in "Microsoft.Extensions.Logging" and
> "Microsoft.Extensions.DependencyInjection." You can see the work in
> progress at a repo on my GitHub, where we have been integrating his work in
> preparation for eventually moving this into an official Apache repo for our
> project: https://github.com/paulirwin/lucenenet-extensions
>
> Please note that the work there is incomplete (some is still going through
> review in a PR), does not yet have proper license setup, minimal and likely
> inadequate CI, no versioning or NuGet details, etc. Nehan and I are
> actively working on moving his prototype code into near-final form in this
> repo as I write this. This vote is NOT intended to be a reflection on
> whether or not this code is good to merge into a new repo nor publish to
> NuGet. I only provide the link here so that you can view the code and
> project structure if you are interested, to get an idea of what Nehan did
> for this project.
>
> At first, we will have these Extensions available, but may add others as
> demand and community contributions dictate:
>
> - Lucene.Net.Extensions.DependencyInjection - core MEDI extension
> methods to aid in registering index readers, writers, searchers, etc. in
> modern .NET applications
> - Lucene.Net.Extensions.AspNetCore.Replicator - ASP.NET Core 8+ support
> for index replication
> - Lucene.Net.Extensions.SelfHost.Replicator - .NET BackgroundService
> support for hosting a Lucene.NET replication server (uses ASP.NET Core
> Kestrel under the hood as an implementation detail, but is designed to
> be
> used in non-ASP.NET Core applications such as Windows/Linux services)
>
> So, why not merge this into the main Lucene.NET repo? Well, these are
> intended to track modern and rapidly-evolving versions of the underlying
> dependencies (i.e. Microsoft.Extensions.DependencyInjection, ASP.NET Core)
> and we need to be able to update those out-of-band of a Lucene.NET release.
> Also, we would like the flexibility to launch new extensions projects in
> the future without having to also do a Lucene.NET release or tie it to the
> Lucene.NET versioning.
>
> At the start of this project, I worked with Shad to come up with the
> direction for the package names. We will welcome any feedback on the
> individual package names (or any other feedback you have) once the code is
> PRed for introduction into this new repo. We just want to have an
> established repository name and corresponding namespace and package prefix
> before we begin.
>
> As far as the repo name goes, Apache sub-repos for our project must start
> with `lucenenet-`, so that part is non-negotiable. I figured
> `lucenenet-extensions` is simple, memorable, and concisely describes the
> contents.
>
> Given that these packages are intended to be consumed by the public on
> NuGet once released, the release of these packages will go through the
> normal Apache release vote and process (unlike the previous vote for the
> exception for the internal-use code analysis packages). But releasing these
> is not up for vote at this time.
>
> Now that you can see what this project was all about, here's what I'm
> asking for a vote on:
>
> - Approval to set up a new `lucenenet-extensions` Apache repo, much like
> we did recently for `lucenenet-codeanalysis-dev` (including approval of
> the
> repo name)
> - Approval of the *name* *only* of the Lucene.Net.Extensions.*
> package/namespace prefix
>
> This vote does NOT approve the release of any packages or artifacts: this
> is NOT a release vote.
>
> Only votes from the PMC are binding, but everyone is welcome to vote.
> Please reply with your +1 or -1 vote, with or without any comments.
> The vote passes if at least three binding +1 votes are cast.
>
> Thank you,
>
> Paul Irwin
> Lucene.NET PMC Member
> Apache Software Foundation Member
>