NightOwl888 commented on issue #1037: URL: https://github.com/apache/lucenenet/issues/1037#issuecomment-2492070440
> Is there a good reason to keep it on netstandard1.x? I don't think those older IDE versions would even support our codebase currently. Microsoft recommends netstandard2.0 at the link above (see my edit), so I would suggest we go with that instead of suppressing the warning. These analyzers are for users, not for our codebase. There is no reason why someone who is stuck on VS2017 couldn't load our library, but they will get a bunch of load failures if they don't suppress the analyzers when they are on an IDE that isn't compatible. - #394 So, this may create usability issues if we upgrade again. Microsoft also specifically requested this feature (although I couldn't find the conversation when I searched) and I don't know whether they still need it or not. IMO, it is less trouble to suppress an irrelevant warning than to deal with usability issues (again). Not to mention, I think there may be more to it than just changing the target framework. > As for the dev-targeted analyzers, my current thought is I think those should be versioned in our repo if at all possible. If there were an exception to the 72 hour vote rule, we could. Otherwise, this would become an obstacle for releasing our analyzer changes in a reasonable timeframe. These dev analyzers won't be embedded in our .nupkg like the user analyzers are. The IDE requires a different assembly version for each release due to caching, so it is easier to deal with as a package reference than trying to bootstrap the latest version into the current build. It will need to be a publicly available package reference so anyone who wants to contribute can depend on it. We would also need to have independent versioning and releases from Lucene.NET so we can update the analyzers between Lucene.NET releases easily. So, it will require an independent build from our current one. It just seems like it would be easier to keep this in a separate repo so we can push it out to NuGet and then bump the dependency version in this repo much like we would for RandomizedTesting or Spatial4n. -- 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