I am working in the latest version of the Bixby IDE ( Version 6.2.0-rc.5484 )
I have downloaded at the example.spaceResorts from git hub (https://github.com/bixbydevelopers/space-resorts)
I compile and get 29 warnings that are all deprecated warnings or this item may be empty.
viv.geo
viv.entity
viv.contact
one gives the new usage. ie. 'hALgihn' is deprecated. Please use 'halign'
Where do I find out what the viv ones should be now?
If you are getting deprecated warnings, it's always good to check that you are using the latest version of the library capsules. This will not solve all deprecated warnings but can help.
Here is the list - last updated Nov 18:
Library - Capsule Version
viv.business - 4.29.0
viv.contact - 2.5123.0
viv.entity - 3.11.13
viv.geo - 9.6.3
viv.image - 2.8.1
viv.measurement - 2.9.2
viv.money - 2.16.19
viv.navigation - 1.7.17
viv.openHours - 3.18.0
viv.rating - 2.14.4
viv.self - 3.2.24
viv.time - 2.63.9
See the docs at: https://bixbydevelopers.com/dev/docs/dev-guide/developers/library
I am a member of the Bixby Developer Support team. The good news is that these are warnings and deprecations, so it will not affect the execution of the capsule. Unfortunately, there is not much you can do about the errors (e.g. ERROR_DEPRECATED) coming from the library capsules (viv.geo etc).
We will however be updating our sample capsules to use halign instead of HAlign. More details on halign can be found here: https://bixbydevelopers.com/dev/docs/reference/type/layout-macro-def.content.title-area.halign
Related
I am just curious, what is carbon, boron, argon which is used while describing versions of nodejs?
Actually Node.js provide code name for Long Term Support (LTS) versions.
It started from Argon (version 4.2.0 to 4.9.1). And then it went like Boron (6.9.0 to 6.16.0), Carbon(8.9.0 to 8.15.0) and Dubnium (10.13.0 to 10.15.0). Basically they name their LTS versions under Chemical elements.
Argon(Ar), Boron(B), Carbon(C) and Dubnium(Db).
They are the code names for the Nodejs versions (based on chemical names from the periodic table, names are taken alphabetically a, b, c ...), please check below link for more details,
https://nodejs.org/en/about/releases/
Now the second part,
Always try to use the stable and latest version (LTS) of Nodejs in production, currently, it is 12.18.3. But for experimenting you can go with the current version and play with new features.
With version 8+ you get async-await support of javascript in Nodejs
Don't bother with the previous version if you are starting new.
I don't know if I get your question right, but according to https://nodejs.org/en/blog/release/v8.9.0/, https://nodejs.org/en/blog/release/v6.9.0/, and https://nodejs.org/en/blog/release/v4.2.0/, these are the names of the releases.
I want to know how to choose the versions of the dependencies used by azure-iot-sdk-c.
for example, I plan to use:
azure-iot-sdk-c from github.com/Azure/azure-iot-sdk-c.git, release_2018_02_09_after_bump_version(3deb0ca3a8e2d220a50175bef71d16d1650a3a79),
then how do I know the right submodule/library versions for it? for example, the sub-modules in https://github.com/Azure/azure-uamqp-c/releases, github.com/Azure/azure-umqtt-c.git ...?
Thanks in advance.
Software and library is managed using the version. And libraries should be designed backwards-compatible when the MAJOR version is same.
A common way to find the suitable version for GitHub project's sub-modules is looking the release date of that project. For example of Azure-iot-sdk-c_release_2018_02_09, the version sub-module of azure-uamqp-c is 1.x.x published before 09/02/2018, so we can use any version of 1.x.x azure-uamqp-c. And of cause, the recommend version should be the latest version of that major version(1.2.3) at present.
More detail about concept of version and sub-modules, you can refer the links below:
Working with submodules
Semantic Versioning 2.0.0
If anyone else lands here after searching the error message of 3deb0ca3a8e2d220a50175bef71d16d1650a3a79;
I found this (https://github.com/Azure/azure-iot-sdk-c/blob/main/doc/master_to_main_rename.md) which refers to azure iot branchn renaming from master -> main on Dec 1st -21, which may explain the trouble finding the reference.
By updating my *.bb file which refers to the github with:
git#linktoyourgit.com ;main
This will reference the specific branch main to find the correct revision.
I have an extension that I recently upgraded to manifest version 2. To do this I removed the background_page property in the manifest file and replaced it with background: {page: "background.html"}. This works and everything is fine. Turns out, however, that there are browsers and people out there with old versions of Chrome, or versions of Rockmelt and other Chromium-based browsers that don't support the background-property, or the manifest_version: 2 yet.
A simple solution would be to just add the background_page: "background.html"-property to the manifest file, in addition to the background-property. This gives the warning in chrome://extension developer mode:
There were warnings when trying to install this extension:
'background_page' requires manifest version of 1 or lower.
My question is: can having both have any negative impact? For example, what will happen when background_page is deprecated? Will my users see any warnings? Any ideas?
You should replace "background_page" with "background".
Like:
"background": "background.html"
Rather than:
"background": {"page": "background.html"}
Even thought having undocumented, deprecated or experimental attributes in manifest.json gives warnings, these warnings are only visible with "Developer mode" active. They don't affect end-user. In my option you are perfectly fine keeping background-page: in your manifest.
You can also consider using minimum_chrome_version to block users with older browsers from downloading your latest update. It's a bit too late for that (since your manifest_vesion: 2 update is published) but you can do a small trick here. Downgrade to manifest_version: 1, wait for everyone to download downgraded version and, yet again, push update with manifest_version: 2 this time adding minimum_chrome_version: 18.
Hi I have an XCode project which is ARCd but uses some 3rd party (AFNetworking) classes which are not ARCd. I have specified the -fno-objc-arc flag against these files however when I run scan-build I get a number of errors such as:-
error: 'autorelease' is unavailable: not available in automatic reference counting mode
I can see that scan-build is using -fobjc-arc when compiling / checking these classes which is incorrect.
Please could someone advise how I can get scan-build to pick up the correct settings?
FYI I am using checker-267 version downloaded from http://clang-analyzer.llvm.org/
Many thanks
Raised this with the clang team at Apple and they swiftly came back to say that this is a known bug, see:
http://llvm.org/bugs/show_bug.cgi?id=13683
A new version of the checker should be released soon to fix this.
Using Installshield 2011, we're creating a major upgrade and having problems upgrading software with this Product Version format - 2009.727.1365. We keep getting the standard 'Installed software is newer than product to be installed' message. With IS 2011, the major version has to be less than 255, from what I can gather, and I think the old format we're using is breaking the check for upgrading.
I've created a test IS project upgrading from 1.00.0000 to 2.00.0000 with no issues, so I'm thinking the issue has to be related to the format of the product version already installed.
Is there a way to use InstallScript or something to compare our old format with the new one and then do an override?
Any help would be greatly appreciated. Thanks in advance!!
**I ended up using Christopher's reply in the link he provided below (Exceeding Version Limits). This seemed to handle the uninstallation of the existing product very well. Thanks again Guys!
It sounds as if you'll need to remove or modify the ISPreventDowngrade major-upgrade item, which is what detects and prevents this kind of version downgrade (and which is usually what one wants).
(Posted follow-up to question here, too: http://community.flexerasoftware.com/showthread.php?t=195076.)
Your ProductVersion property is invalid. The SDK says:
The value of the ProductVersion property is the version of the product in string format. This property is REQUIRED.
The format of the string is as follows:
major.minor.build
The first field is the major version and has a maximum value of 255. The second field is the minor version and has a maximum value of 255. The third field is called the build version or the update version and has a maximum value of 65,535.
I also recommend reading Exceeding Version Limits.
There are hacks to work around this if you understand how FindRelatedProducts and RemoveExistingProducts works.
Even though this is an older I'd like to add my two cents.
I am creating an Installshield 2012 Spring project and I had the same issue.
Our previous installers had a Product Version in the format 2005.xx.xxxx. Obviously this 2005 was an issue.
Instead of setting the ISACTIONPROP1 property to any value (as mentioned in http://community.flexerasoftware.com/showthread.php?195076-Old-Product-version-in-2009-727-1365-format).
I added a major upgrade item with the following values:
Product code of the old installers: xxx (enter yours here)
Minimum version: 2005.001.0001
Maximum version: 2005.255.65535
Version Range Inclusive (might be overkill)
With this, the system does allow the 2005.xxx.xxxx format here. It detected and removed the previous installation. For our newer installations we will use our "normal" versions:
5.008.0001
5.009.0001
...