NightOwl888 commented on issue #747: URL: https://github.com/apache/lucenenet/issues/747#issuecomment-2654465947
> 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. In principle, I don't have an issue with creating a separate repo for this. However, as I mentioned above, there is a dependency on `Lucene.Net.Replicator.AspNetCore` from `Lucene.Net.Tests.Replicator`. So, splitting this off is not quite that straightforward. ### Options 1. Add a `<PackageReference>` on the new AspNetCore-speicific NuGet package from `Lucene.Net.Tests.Replicator`. 2. Move the `Http` tests to the new repo. 3. Don't put the new package into a new repo, but use a separate tag scheme to track the releases of the new package. 4. Move both the `Http` namespace and the `Http` tests to the new repo. Option 1 would end up creating a situation where we would always be a version behind in the Lucene.Net release tests (keep in mind, the release is the source code). We wouldn't be able to update the tests until the new package is released. For Option 2, there are dependencies on `ReplicatorTestCase`. `ReplicatorTestCase` is subclassed by all of the other tests, but a search reveals that only `MockErrrorConfig` is shared between them. They don't have to subclass `ReplicatorTestCase` at all, apparently. However, there is a potential issue with this configuration - `Lucene.Net.Replicator` would be released without running any of the `Http` tests because they wouldn't be in the lucenenet repo. Option 3 is what Lucene did with SOLR in 4.8.0 - there were separate tagging conventions for each product, so they could be released independently. But (as is the case here), they could be released and tested together when Lucene.NET is released. Our CI would have to be changed a bit to accommodate this (and something like Nerdbank.GitVersioning to version the 2 products independently - which is something I am hoping to use, anyway). Option 4 seems like a good option. Upon a cursory review, 2 of the 3 types are abstracted to interfaces. `HttpClientBase` is the one exception. We would have a similar issue duplicating `ReplicatorTestCase` as in Option 2. One drawback of doing this is that our replicator package will diverge from upstream. But, if there were ever a need to create something other than extensions for AspNetCore (some other protocol or alternative HTTP APIs), it might be more sensible to ship a different implementation in the new package, anyway. Maybe there are more options that I haven't thought of. Thoughts? -- 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
