Closed wesrupert closed 8 years ago
@wesrupert do you have a concrete example where and how you would use a version check in a debug adapter?
I'm asking because we tried to stay away from this kind of version number checking and prefer to use individual feature flags (capabilities).
@weinard Wes is currently looking at it to consume the new type
support for variable info. If we drop the annotation today, then users will not be able to see types until they upgrade to the June release, which means that we cannot checkin our work for a few weeks. We would like a way to checkin our work, and have it lightup as soon as a user is running an IDE that supports types.
Adding some sort of 'client capabilities' section to the initialize request could certainly work too. We should need to make sure that we are good about keeping that up to date. A protocol version field therefore seems like it might be an easier catch-all. But either way is fine with us.
We will start by adding individual flags to the InitializeRequestArguments
. The first flag is supportsVariableType
.
Please create new issues for any protocol feature that a debug adapter needs to know.
Currently, there's no way for a debug adapter to determine whether or not a user is using a sufficiently up-to-date version of VS Code to support features that depend on protocol changes or additions. Adding a way to check the protocol's version (e.g. passing the version during the initialize step) allows debuggers to light up new features gracefully as soon as the adapter supports them, without providing a broken experience for users that are not fully up to date.