I see each cfx tools always produce xpi with its own minVersion and maxVersion. However, those are limited to the versions which the SDK is compatible with, e.g. SDK 1.14 only for FF 21 - 25.0a1 , SDK 1.17 only for FF 26 - 30. My questions are:
Do I need to package my extension with new SDK everytime new version comes out ?
How do I maintain and update my extension in the future? Does Addon Developer Hub provides a way to submit the same extension for multiple SDK versions ? I tried to look around but couldn't find a way to submit multiple versions.
I want to make FF 21 as the minimum version, since that's the version which has SDK built-in. My extension currently compiles with both SDK 1.14 and SDK 1.17 with only cosmetic(syntax) adjustment.
The developer hub lets you choose which versions of Firefox the add-on is compatible with. This is just a GUI for setting the minVersion and maxVersion in the install.rdf. As long as you don't use modules or methods that require Firefox 22+, it shouldn't matter which version of the SDK you use, as the version of the SDK being run is determined by the version on your user's browser.
It's hard to find module specific compatibility (you can always go to the docs for the specific module and look at the edit history), but have a look at the SDK API Lifecycle to understand which modules can be used. Some notable example are:
The new UI modules require FF29 and some of their features require FF30.
The widget module is deprecated from FF 29 onwards, being replaced by the above.
One way to handle the above for backward compatibility is to do the following:
const { version } = require('sdk/system/xul-app');
if (version < 29) var widget = require("sdk/widget").Widget({...});
else var button = require("sdk/ui/button/action")({...});
So, to be clear:
It doesn't matter which version of the SDK you use unless you want to use new modules.
No, you shouldn't make multiple versions of your add-on. If you want to use new modules for new browsers, follow the code example above.
It's true that you must use valid existing application versions but you generally don't need to repackage your addons, unless of course a change in the SDK directly affects your addons.
The reason for this is that by default the max target version is not going to be checked.
From the install manifest documentation:
strictCompatibility
A Boolean value indicating if the add-on should be enabled when the version of the application is greater than its max version. By default, the value of this property is false meaning that the compatibility checking will not be performed against the max version.
<em:strictCompatibility>true</em:strictCompatibility>
Usually, there is no need to restrict the compatibility: not all new releases will break your extension and, if it is hosted on AMO, you'll get notice several weeks in advance if a potential risk has been detected. Moreover, an extension being disabled, even for a short period, leads to a bad experience for the user. About the only time you should need to set this if your add-on does things that are likely to be broken by Firefox updates. You do not need to set this flag if your add-on has a binary component, since add-ons with binary components are always subject to strict compatibility checking (because binary components need to be rebuilt for every major application release anyway).
There is also is a recommendation for choosing version ranges.
minVersion and maxVersion should specify the range of versions of the application you have tested with. In particular you should never specify a maxVersion that is larger than the currently available version of the application since you do not know what API and UI changes are just around the corner. With compatibility updating it is not necessary to release a whole new version of the extension just to increase its maxVersion.
Technically you can use wildcards, but the documentation mentions several times that AMO verifies and possibly rejects addons with incorrect versions.
Related
I'm not sure if this is the right place to ask this. I've googled this and not really finding the results. I'm using ES6 modules and import/export and load my initial javascript using module type
<script type="module" src="/app.js"></script>
In Chrome its on by default. In firefox you have to enable it in about:config
The problem is I cant have users manually enabling this flag for it to work. Is there a future where this will be on by default in Firefox? At CanIUse, it says that in version 60, its on by default. But every version of Firefox I've downloaded is only version 59.00 (Windows). I would like to avoid babel if possible.
Is there a future where this will be on by default in Firefox?
Yes.
At CanIUse, it says that in version 60, its on by default. But every version of Firefox I've downloaded is only version 59.00 (Windows).
You can download the nightly build here.
I would like to avoid Babel if possible.
Well you cannot avoid if you want to support older browsers that do not (yet) support this feature.
For example: My Xcode project deployment target can be iOS 10.3 — Is there an equivalent to require macOS 10.12.4? (Latest SDK)
• iOS 10.3 is the latest update (can be targeted in Xcode).
• macOS 10.12.4 is the latest update
My goal/hope is to target the latest macOS update in the same way I can target the latest iOS update.
Verdict: It’s not (yet?) possible in Xcode. :(
While building you can define a deployment target. This is a specific API level for the minor versions of the operating system. This will run on all patch level versions for this particular minor version. So there is little point to set deployment targets on patch level.
You can check that you run your applications on certain operating system versions only though with a little code.
operatingSystemVersion and isOperatingSystemAtLeast(_:)seem to do what you want to achieve:
https://developer.apple.com/reference/foundation/processinfo/1414876-isoperatingsystematleast
You can then exit and deny using the application if the desired criteria is not met.
P.S. iOS deployment lets you chose iOS version 10.3 only too. There is no specific option for iOS 10.3.1 for example.
Can't you select such an option when you set your deployment target?
The page linked to also states:
Xcode sets the Minimum System Version key in the app’s information
property list to the deployment target you choose. When you publish
your app to the store, it uses this property value to indicate which
versions your app supports.
So you might change it by adapting the information property list as well I presume..
I was able to set a minor release version by editing my project's project.pbxproj file, located within your xcodeproj bundle.
Once you've located your project.pbxproj file, open it and
search for MACOSX_DEPLOYMENT_TARGET. You can set its value to any valid macOS version (no quotes needed).
The result is correctly displayed within Xcode's UI, and most importantly, is respected when compiling. I've confirmed this by using #available directives.
I have some xamarin.forms 1.xx( I dont know which version) project on multiple platforms Android and iOS. And I've been asked to upgrade it to the maximum available right now version of xamarin.forms.
Therefore, I have 2 questions:
1) How to determine which version of forms I'm using right now (I'm working in Windows environment using Visual Studio 2015 ).
2) How to migrate/update to newest version of forms? (step by step, if it's possible). I have no idea how the result of that kind of operation supposed to look like, cuz I have never done anything like this before in my life. And what the best practices are?
What I've done is opened VS2015->Help->Xamarin release notes, however there was nothing about version of Forms I'm using. Also, I went to the official xamarin website and there was no guide how to do that. I also tried to look at the release notes the last Forms update and trying to find and fix differences, but my project is so big and I thought that this way doesn't seems right.
I'll answer first the What are the best practice regarding upgrading a Xamarin.Forms application? first and then address your other concerns.
I recently upgraded from 1.5.1 to 2.3.2, and from my experience, this is the steps to go through:
Decide which version you will upgrade from and to.
Read the change logs for all stabled releases between these two versions and look for breaking changes/bugfixes. You can find the release notes on Xamarin's website or on NuGet's website too.
Check regularly for new releases on the Xamarin.Forms forum and check if any reported issues may affect you. Every time Xamarin makes a release, there is a thread full of comments from other developers that may have encountered issues you might be interested in.
Using your favorite versioning software, make sure that all local changes are commited or stashed and create a new branch for your Xamarin.Forms upgrade (you don't know how long the upgrade will take and you still want to be able to send patches during the process)
Upgrade: Read the Important notes at Xamarin.Forms 2.3.2 release notes, especially the When upgrading Xamarin.Forms take care not to simply "update all" as ... part. Remember to upgrade on your PCL project, on your iOS project and on your Android project.
Test your whole app on as many devices as possible and for the longest possible period before you merge your branch back into your development/master/Main branch and address the potential incompatibility issues that may have been created in your development/master/Main simultaneously.
Step 3 is very important as it will allow you to reset back to your starting point and restart if you should fail to upgrade for whatever reason.
Xamarin.Forms is moving fast so it's important that you always keep an eye on what's going on even if you don't upgrade.
Which version am I using right now?
You can check that in the NuGet package interface or in the packages.json file in your project.
I am facing a problem while packaging my latest software version in windows 7.My latest version of software is not compatible for upgrade.So if a user already have old version of software , i have to stop the installation (disable next button in the installation windows)or give some notification to Customer to remove the older version.
Is it possible this in install shield(2015)?
You will probably want to follow the same mechanism as ISPreventDowngrade uses. In the Upgrades view, there is a major upgrade item configured as Detect Only. Then in the Custom Action and Sequences view, there is an error action that only fires if the action property of that upgrade item is set.
If you duplicate both of those items with a new action property (and thus new condition), and change the upgrade item to find your earlier version range instead of future versions, you should be able to get the behavior you want.
If you expect there's a specific threshold of versions (i.e. upgrading from anything 1.0-4.0 to anything 5.0 or later requires this, but upgrading from 5.0 to 6.0 will not), you can configure the version range explicitly. If instead you expect you will always need this in the future, you can search for any previous version and let the upper range match your product. Either can be changed for any release in the future.
I'm new to Firefox extension development, friendly speaking it's first day, I had followed the following article in order to start with Firefox extension development: How to develop a Firefox extension.
If I download the example from above given link's tutorial and try to install, it is installed perfectly but, when I update that example (just updating its name to the new extension name, where it is necessary in all files), and then install, I get the following message: "X could not be installed because it is not compatible with Firefox 15.0.1." (where X is the name of my extension).
Strange behavior same code one is installing fine and other one giving error.
Any idea where it is going wrong and what is causing this?
The problem is that you forgot to adjust the compatibility range in install.rdf so em:maxVersion is still saying 3.1b2 (meaning Firefox 3.1b2 - a rather old version). You should change that into 15.* if you want to support the current stable Firefox version or 16.* if you want to support the current beta versions. You can also change em:minVersion into something more meaningful: I doubt that you will verify whether your extension still works with Firefox 2.0.
As to why the extension installs if you don't change the extension ID, this is more complicated. First of all, there is a soft override mechanism for the compatibility ranges which allows extension authors to change the compatible version range without releasing a new version. In this particular case Firefox will check for extension updates by requesting this address or a similar one. The update server tells it that version 1.0 is still current but adjusts maxVersion to Firefox 8.0 - this value will override whatever is specified in install.rdf.
But that's not the end of the story. The compatibility check mechanism was changed significantly in Firefox 10, the default assumption is now that the add-on is compatible with newer versions even if that isn't specified explicitly anywhere. The requirements are that the extension doesn't opt out of lax compatibility checking, doesn't contain binary components and is compatible with at least Firefox 4. The original extension is compatible with Firefox 8 thanks to the soft override, with a different extension ID it is only compatible with Firefox 3.1b2 however (it isn't hosted on addons.mozilla.org so the update server doesn't know about it) which means that the lax compatibility checking doesn't apply to it.
For reference: the behavior described in the previous paragraph is controlled by the extensions.strictCompatibility, extensions.minCompatibleAppVersion and extensions.minCompatiblePlatformVersion preferences.