-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do we need to add version information to the monikers #10
Comments
The high level requirement for LSIF monikers should be that an equivalent pair of monikers exist if and only if the symbols that they label are equivalent as the developer would expect them to be. Matching runtime behavior for the application exactly is not a requirement, but if a user executes a GTD or FAR command, the results are entirely based on a moniker matching and thus monikers should be precise enough to avoid false matches but fuzzy enough to ensure the reuslts are complete. For .NET I think we'll almost certainly not want to include version info since virtually everyone will use binding redirects on .NET or ignore versions on .NET Core making type equivalence disregard assembly version at runtime. Customers will expect a reference to For other languages to deviate from this and include version info in the moniker, I'd be interested in hearing the case why we should not consider a symbol to be equivalent across versions. On the other hand, we should have version information as precisely as we can get it, from the package and the assembly (where applicable), in the LSIF for all imported libraries so that we can have GTD jump across repos. |
Considering the scenario of GTD jump across repos, just as @AArnott has said, the monikers should contain version information to make sure it will point to the right place in another repo as precise as possible. |
The new format has a package information vertex which can carry a version identifier. |
No description provided.
The text was updated successfully, but these errors were encountered: