paulirwin commented on code in PR #1: URL: https://github.com/apache/lucenenet-codeanalysis-dev/pull/1#discussion_r1992727258
########## src/Lucene.Net.CodeAnalysis.Dev/AnalyzerReleases.Unshipped.md: ########## @@ -0,0 +1,9 @@ +### New Rules Review Comment: After removing the generated Resources.Designer.cs file (and having it auto-generated on build), having to merge/rebase to change rule IDs is no longer as big of an issue. After thinking about it more, I also don't think we're going to be having so many analyzers that this is a huge problem. I'd like to propose we do a simpler solution: we can still have the text file of reserved IDs, but we treat main as the source of truth for this file, and allow committers to reserve an ID by committing a change to this file without having to go through a PR. They can then create the PR using that ID. If another contributor comes along to add another analyzer, they will follow the process (which will be documented in the README/CONTRIBUTING file), pull latest main, add the next ID to the end, commit their change to the text file to "lock in" their ID, and then do their PR. And if a contributor skips that part of the process and submits a PR for a conflicting ID, then it will be on them to reserve a new ID and update their PR with the new ID. I don't think we need the complexity of having a test/meta-analyzer for this, it feels like overkill. We are currently at 5-ish analyzers, and I don't see us growing to where this will be a huge problem. We can also always add it later, too, if really needed. -- 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]
