You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SGTM. #1832 was (is) a necessary condition for me to be able to use vscode-R at work, so I'd be grateful to have that available in the release version ASAP.
P.S. I imagine that this would be taken care of as part of the release, but the sess versioning seems to be out of whack. It's currently denominated as 3.0.9000.9001.
P.S. I imagine that this would be taken care of as part of the release, but the sess versioning seems to be out of whack. It's currently denominated as 3.0.9000.9001.
As far as I understand, this is not a problem because vscode-R no longer checks for the sess version.
#1832 was (is) a necessary condition for me to be able to use vscode-R at work, so I'd be grateful to have that available in the release version ASAP.
Could you try daily pre-release version?
Please check README.
To receive daily development updates, choose Switch to Pre-Release Version on the R extension's page in VS Code. New pre-releases are published to the VS Code Marketplace and Open VSX Registry when main changes and verification passes. Choose Switch to Release Version to return to stable releases. When reporting problems, include the extension version and reproduction steps.
Thanks @eitsupi , confirmed that works locally. But my work situation requires a containerised solution, with pinned versions of our different SW, so I'd prefer to wait for the formal 3.2 release. (Otherwise my SDE team is going to get grumpy.)
As an aside, I think it could be simpler to give the CLI equivalent of the above steps in the README, which is just:
All the issues listed in the milestones have been resolved, so I have pre-released version 3.1.20261011.
If we are able to use this version without any problems, would it be alright releasing version 3.2.0?
Activity
renkun-ken commentedon Oct 5, 2026
Agree
Fred-Wu commentedon Oct 5, 2026
Agree
eitsupi commentedon Oct 5, 2026
Thanks.
#1741 includes breaking changes to the sess package, so if we include #1741, I would like to remove deprecated functions from sess.
eitsupi commentedon Oct 6, 2026
Related to #1751, maybe we should choose 3.2.0.
[-]3.1.0 release[/-][+]3.2.0 release[/+]grantmcdermott commentedon Oct 6, 2026
SGTM. #1832 was (is) a necessary condition for me to be able to use vscode-R at work, so I'd be grateful to have that available in the release version ASAP.
P.S. I imagine that this would be taken care of as part of the release, but the
sessversioning seems to be out of whack. It's currently denominated as3.0.9000.9001.eitsupi commentedon Oct 6, 2026
As far as I understand, this is not a problem because vscode-R no longer checks for the sess version.
grantmcdermott commentedon Oct 6, 2026
Good to know, but I still think we should fix the versioning (the double
*.9000.9001semantic suffix is strange, right?)eitsupi commentedon Oct 7, 2026
Could you try daily pre-release version?
Please check README.
grantmcdermott commentedon Oct 7, 2026
Thanks @eitsupi , confirmed that works locally. But my work situation requires a containerised solution, with pinned versions of our different SW, so I'd prefer to wait for the formal 3.2 release. (Otherwise my SDE team is going to get grumpy.)
As an aside, I think it could be simpler to give the CLI equivalent of the above steps in the README, which is just:
eitsupi commentedon Oct 11, 2026
All the issues listed in the milestones have been resolved, so I have pre-released version 3.1.20261011.
If we are able to use this version without any problems, would it be alright releasing version 3.2.0?