I have VS Code portable version and now I get the latest version.
I want to know how to update to the new version. Should I replace all files? If so, what about my configuration? I want to keep my old configs.
Related
I am developing my VS Code extension. Old version is 1.0.0. I add a new feature which leverages VS Code's new feature Remote-development, which only available with VS Code engine version higher than 1.36.1. I added my extension new feature and upgraded my extension to 2.0.0.
I would like to restrict user's VS Code engine when installing my extension. If user would like to install my extension v2.0.0, he must have VS Code engine version higher than 1.36.1.
I set the minimum VS Code version restriction in extension's package.json file, engines fields, following VS Code Official Docs: Extension Manifest. But later I figured out that user with VS Code engine version lower then 1.36.1 still can search my 2.0.0 extension and install it. VS Code does not pop out any suggestion to inform user to upgrade their engine. And the extension can not work properly, of course.
// package.json
"engines": {
"vscode": "^1.36.1"
}
Did I miss something?
How can I restrict user with lower VS Code engine version either to upgrade their VS Code engine or install the old extension release?
Now user with lower VS Code engine version just install my new extension release and the extension can not work. Any help is appreciated!
I figured out the reason myself:
VS Code package.json's engines field does work. If user's engine lower than the required minimum engine version, VS Code will install lower version extension for user.
In my scenario, I have a dependency extension, whose engine requirement is not aligned with the main extension. This is the root cause of the main extension installation failure.
When user with lower version VS Code engine tries to install my extension, VS Code checks the dependency extension's engine requirement and fails to find a main extension release with proper dependency release. In this case, the installation of main extension fails.
Solution:
I have to find a way to remove my previous extension release from marketplace, whose engine requirement is not right.
The documentation (https://code.visualstudio.com/docs/languages/json) does not say specific version. I know that VSCode supports draft-04 for sure as I am using it, but I wonder if it supports draft-06 too.
I have a few apps (already working) running parse-server on Heroku and using mLab mongoDB.
I need to upgrade parse-server to a new version.
What is the simplest (an best) way to do that?
Ensure compatibility by testing locally first, of course. To upgrade the version you change your project's package.json file. There should be a dependency "parse-server": "a.b.c"
"a.b.c" will use an explicit version.
"~a.b.c" will use the latest version matching "a.b."
"^a.b.c" will use the latest version matching "a..*"
a is a major version, which is not always backwards compatible.
b is a minor version, which generally includes new features but should be backwards compatible, so ^ is usually safe to use.
c is a patch version, which is generally bug fixes and security updates, though I think parse-server has included minor feature updates here as well.
On Ubuntu 15.4 and they worked once after a few reinstalls and now I just can't place them. Using the latest version.
I suggest you file an issue over at GH and indicate which node version you are on: https://github.com/Microsoft/vscode/issues
Whenever there is a new node.js version, our debugger might need to adopt new semantics. It could be that we are not yet supporting node.js 5.0.
I am working on developing an software.
I have installed the v1.0 on my machine running solaris 10,
and I want to upgrade to version 1.1 tha has some new function.
I do not want to uninstall version 1.0 but upgrade to version 1.1.
How do I make a patch?
Writing a script or using some patch tools?
If you are asking about Solaris patches, i.e. those appling to SVR4 packages, I guess only Solaris engineering is able to build and deliver them as there is no standard/documented format I'm aware of. The new version of Solaris (11) is going to abandon this patching method anyway to the new pkg mechanism.
If you want a new version not to replace the older one, I guess the simplest way would be to have them to install in different directories. eg: /opt/zhangli/v1.0 and /opt/zhangli/v1.1. Any packaging format would support that.