stevedlawrence commented on issue #39:
URL: https://github.com/apache/daffodil-vscode/issues/39#issuecomment-946641980


   I didn't know that was a requirement. And I'm not even sure it should be.
   
   I would imagine when a user installs `daffodil-debugger-X.Y.Z.vsix`, that we 
have tested that version of the debugger with a specific version of Daffodil 
that is included in the .vsix. In order to get a new version of Daffodil, we'll 
need to release, and a user will need to install, an updated version of the 
.vsix file with a new version of Daffodil.
   
   I would be afraid that allowing a user to switch between different versions 
of Daffodil would be fragile, and not even all that necessary. I would expect 
they would just want the latest, which just means daffodil-debugger releases 
should coincide with daffodil releases, which I suspect would be the case 
anyways--each time we release Daffodil, we're going to want to make sure the 
new release works with the Debugger, so that testing should already be done.
   
   If we really wanted the user to be able to pick different daffodil versions, 
another option is to move this debugger-dap stuff into daffodil proper, and 
only the .ts files live in this repo. When a new version of Daffodil is 
released, the daffodil-dap tool is updated, and the extension will use that. 
Users can install whatever version of Daffodil they want. The downside here is 
we may want a more frequent release candence with dafodil-dap than the 4-6 
months that Daffodil seems to be following.
   
   Or another option, we require that Daffodil proper already be installed, and 
this extension includes only the daffodil-dap jar. This extension would find 
where Daffodil proper is installed (or its' a config option) and set up the 
classpath correctly so that it can execute daffodil-dap along with whatever 
version of Daffodil is installed on the systems. And then a user can update 
Daffodil on the system however they want. It means we need to be much more 
careful about ensuring Daffodil API binary compatibility, but that's something 
we should already be doing anways.


-- 
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]


Reply via email to