paulirwin commented on issue #747: URL: https://github.com/apache/lucenenet/issues/747#issuecomment-2652327403
Proposal: We should consider moving this (ASP.NET Core Replicator support) into its own repo (i.e. lucenenet-aspnetcore) for out-of-band releases to decouple this library from Lucene.NET's releases, and remove this from scope from 4.8.0. (There is a separate discussion about whether we should abstract this further, i.e. to support non-ASP.NET-Core service replication via Microsoft.Extensions.DependencyInjection, but if we do that, this new project/repo would likely just depend on that project anyways, and doesn't change the rest of this comment.) ASP.NET Core moves much faster than Lucene.NET does, and so there will likely always be a tension between which version of ASP.NET Core to support, versus when we can release Lucene.NET, if we don't do this. For example, should we target ASP.NET Core 8 (LTS) or 9 (STS) today? What about when 10 (next LTS) comes out in just a matter of months from now? We can't easily support multiple versions of ASP.NET Core in the 4.8.0 release. If we can decouple the versioning of any ASP.NET-Core-dependent libraries (now or ones added in the future) and tie them to the currently-supported ASP.NET Core releases, where it depends on the latest Lucene.NET, then it can grow and evolve independently without forcing a Lucene.NET release in order to catch up, as well as allow us to support multiple LTS/STS versions in parallel. Also, this would allow us to do this work after 4.8.0 is released, or at least in parallel at the tail end of the development cycle to where it doesn't hold up the release, and remove it from scope. I think everyone that follows this project would rather roll their own replication using this code as an example if needed than have the 4.8.0 release be any further delayed. I would suggest that we pin the major version number of this split-out project to the ASP.NET Core release that it targets. For example: - 8.0.x - ASP.NET Core 8 LTS, Lucene.NET 4.8.0 (EOL Nov 2026) - 9.0.x - ASP.NET Core 9 STS, Lucene.NET 4.8.0 (EOL May 2026) - (later in 2025) 10.0.x - ASP.NET Core 10 LTS, Lucene.NET 4.8.0 or latest (EOL Nov 2028) So between Nov 2025 and May 2026, we would support three versions for bugfix/security updates via patch releases (i.e. 8.0.1), but most of the time it would only be two simultaneous supported releases. Trunk (main) would always target the latest version of ASP.NET Core and Lucene.NET, with bugfix/security changes cherry-picked back to prior supported versions in their own branches where feasible. Older supported versions would not be updated to support a newer version of Lucene.NET, as that might have breaking changes. This will require users to choose which combination of ASP.NET Core and Lucene.NET versions they wish to use based on which versions we publish (i.e. you likely couldn't use a future version of Lucene.NET with ASP.NET Core 8), unless we come up with an abstraction that makes sense that allows for upgrading one and not the other. Also, users would be welcome to lift the code from this repo for their own customization (with proper license attribution of course). But given the current pace of Lucene.NET, this is probably not a problem we have to solve right now, as once we get 4.8.0 out it'll likely be the status quo for a while. I just wanted to open up discussion on this to get feedback to improve this proposal or hear any objections. If it seems like it sounds like a good idea, I'll put it up for a PMC-binding vote on the dev mailing list after giving sufficient time for comment here. Thanks! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@lucenenet.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
