NightOwl888 commented on code in PR #930:
URL: https://github.com/apache/lucenenet/pull/930#discussion_r1523720154
##########
src/dotnet/tools/lucene-cli/lucene-cli.csproj:
##########
@@ -24,22 +24,22 @@
<Import Project="$(SolutionDir).build/nuget.props" />
<PropertyGroup>
- <TargetFrameworks>net7.0;net6.0</TargetFrameworks>
- <RollForward Condition=" $(TargetFramework.StartsWith('net7.'))
">Major</RollForward>
+ <TargetFrameworks>net8.0;net6.0</TargetFrameworks>
+ <RollForward Condition=" $(TargetFramework.StartsWith('net8.'))
">Major</RollForward>
Review Comment:
IMO, allowing the user to roll forward is the best solution. Here is the
situation we are planning for:
Eventually, we will be caught up with the Lucene release schedule, hopefully
to the point where we release every minor version. Some of the lucene-cli tools
that ship with every version of Lucene.NET are **version sensitive** down to
the minor version. Let's say in the future we release Lucene 10.0 through 10.10
on .NET 8, .NET 9, and .NET 10 (lucene-cli is part of that release).
Now a user is using Lucene 10.3 and has his index built on that codec. The
app works fine and is stable on that release, so they stick with it a few years
and all of the .NET SDKs that lucene-cli shipped with are now obsolete. He
doesn't notice this because `net10.0` DLLs will run fine on `net13.0` which he
eventually targets. The user's index gets corrupted and he needs to run the fix
utility immediately. He installs lucene-cli from the command line to do the fix
and then when he runs it there is an error that no supported runtime is
installed because he has .NET 12 and .NET 13.
There are only 4 ways out of this scenario:
1. We plan ahead for this situation and document how to get lucene-cli 10.3
up and running on .NET 13 after .NET 10 is out of support.
2. We plan to do a patch release of every minor Lucene version every time a
.NET version is released so we can stay ahead of the planned obsolescence. In
this scenario, we would need to patch Lucene.NET 10.0 through 10.10 for .NET
11, .NET 12, and .NET 13 (that is, 3 different patches as each new SDK is
released for 11 different releases).
3. The user has to install an out of support .NET runtime in order to fix
his index. And maybe he can't because his company has a policy against it.
4. The user has to download the source code and recompile on `net13.0`, then
work out how to install the the tool from the lucene-cli NuGet package in a
local directory onto his machine before he can run it.
In this scenario, upgrading Lucene.NET to the latest version is not a viable
option because the tools on the latest version may not have binary
compatibility with his index.
The documentation you linked to assumes a Framework Dependent DLL
distribution, not a [dotnet
tool](https://learn.microsoft.com/en-us/dotnet/core/tools/global-tools). Which
kind of underlines my point. You cannot just do `dotnet run` with a .NET tool,
you have to install it from NuGet and it ships with support for specific
runtimes. So a user who ends up there won't have a solution to the problem, and
won't appreciate that we don't have a document to get the tool to fix his index
running.
I *wish* we didn't have to have a `lucene-cli`. In Java, you can simply use
the JAR you have in your app directory and run the tools inside of it on the
command line (in addition to depending on it like a class library). That
approach means that the tool is always available to run regardless of which
version of Java is installed. Unfortunately, since we need an executable to be
able to run on the command line in .NET, we needed another solution that we
could ship with Lucene.NET so the user wouldn't have to deal with compiling
from source. lucene-cli is a wrapper executable that simply cascades calls to
the `Main()` methods inside of the (non-executable) DLLs and also cleans up the
commands to make them more consistent. So, yes there is a guarantee they will
work well because they are the same DLLs that the user is already using that
work well.
Of course, I am open to suggestions about an alternative way to ship the
Lucene tools and to keep them ahead of the .NET planned obsolescence, but IMO
it makes more sense to provide a compiled app that is ready to go than source
code that a user has to build. And then Microsoft made that hard for those of
us shipping version-sensitive code.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
