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

Reply via email to