Will a module created for OXID 6.0 be backward compatible with lower versions (i.e.: OXID 5.0) in terms of installation and activation?
If the new metadata version 2.0 and namespaces are used the module will not be backwards compatible. Modules for version 4/5 did not use namespaces and installation was done by file copy, the new recommended way is to use namespaces and install the module with composer.
Also the database layer has changed in Version 6, if the module has interactions with the database the corresponding code slightly differs from version 4/5 (using AdoDB) to version 6 (using doctrine).
So it might be possible that a module created for OXID 4/5 will work in version 6, but in most cases you will need separate versions of the module.
More information can be found here: https://docs.oxid-esales.com/developer/en/6.0/
No, this will never work this way. OXID6 provides only temporary backward compatibility for older modules. I think they will stop supporting older modules when all oxid-esales modules will be rewritten to new oxid6 format.
Related
I have an question regarding updates to the framework of a Laravel application.
Normally I run the composer update command to update all of its dependencies. For the laravel framework the package laravel/framework is used.
But they made some changes in this package which require you to make changes in the core application (not in composer). The core application is the package laravel/laravel.
For example, in this commit they have made a function called confirmPassword() which refers to a file ConfirmPasswordController.php in the package laravel/laravel.
But this file didn't exists on my application because my application is not up-to-date.
My question
How do i keep my core application up to date?
Errors
See a typical example of updating the dependencies but not the application here.
First of all... This is not an easy question and IMO there are MANY possible scenarios... Depending on the code you developed, the packages you're using, the version you want to use, and so on...
Anyway This is what I would do in this situation:
Let's say for example I want to upgrade from version X to version Z where Z is two major / minor releases ahead of X
Step 1
Follow the next steps for one major / minor realease at time. Once I've tried to upgrade an application from Laravel 5.4 to 5.6 and it was completely broken. So I decided to upgrade to 5.5 and test the everything was working and, in case, block at that release. Luckily when I've upgraded from 5.5 to 5.6 (after code fix) I've managed to make everything work as it should.
Step 2
Upgrade the core framework and the plugins, check for errors during the upgrade and ofc, check the official documentation for any kind of compatibility problem
Step 3
Laravel has it's own upgrade guide that should be followed step by step. A good chunk of errors can be solved simply following that guide. There may be some plugins that doesn't provide it but usually the problems are releated to new features... It's hard that a method, class or trait has completely changed from one version to another.
Step 4
This step can be omitted, but from the example you've provided maybe it's better to add it. When there is a new feature that requires a specific class or trait or whatsoever, the simplest way to check if the error is thrown because of a file missing (and that is part of the "boilerplate") or has a different nature, is to create an empty project with that specific version and make a comparison with the "default" files.
For example, if you made no changes to the LoginController, checking if the new version has any kind of updates, may be the solution.
You can do this manually, following the upgrade guide for the version you're upgrading from/to, for example this one.
Alternatively, Laravel Shift is a paid but fairly inexpensive tool that will do it for you automatically. Since it's making changes to your project, you should carefully review everything it's done.
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.
How to upgrade codeigniter from version 1.0 to recent version?
I have downloaded the recent version of codeigniter and have a sample project which is written in version 1.0. When i try to run it. I am receiving various kinds of errors for using deprecated functions.
You would have to go through http://ellislab.com/codeigniter/user-guide/installation/upgrading.html and make appropriate changes.
Alternatively, you can just battle the errors as they come up until they're all gone.
It might be easier to just re-write the thing.
I want to know if there's any way to update from all versions (Example: 1.7.1, 1.7.2...) to version 1.8.0 using a single file (Example: mysql4-upgrade-1.7.0-1.8.0) from my own module.
there is a delimiter for that?
Thanks
It's not possible to do this in the same file.
When Magento upgrades from one version to another, it will also upgrade all versions in between provided you have the files set up.
So if someone has 1.7.0, and wants to go to 1.8.0, Magento will upgrade from 1.7.0-1.7.1, then 1.7.1-1.7.2 and then from 1.7.0-1.8.0 - providing you include all the files.
Read some more on upgrade paths here:
http://www.magentocommerce.com/knowledge-base/entry/magento-for-dev-part-6-magento-setup-resources
I have an extension package on our corporate nuget server for Asp.Net MVC 3 - let's say the package ID is currently Acme.Mvc and it's version is 2.x.
I've now branched that project and going to put a pre-release version of the same package targetted at MVC 4 Beta. Now, logically this is now version 3.x of the library; however, as soon as I release it (once it's no longer pre-release), the 2.x will no longer appear in VS' UI; which will potentially lead to other developers adding it to their MVC 3 projects; and deny them easy access to any future upgrades to the older v2.x library without using the console).
In a couple of other cases, I've changed the package id to include a version i.e. Acme.Mvc.3 so the new and old can sit side by side. Only problem with that is that it's then possible for someone to try and include both! There's also the slightly pedantic issue that to call that v3.x is not necessarily correct; because it's a new package.
Also, I really need to be able to maintain both streams. I can rely on Binding Redirects in MVC 4 sites that still reference the version of the library that targets MVC 3; since none of my extensions rely on stuff that's gone.
When I look at the public nuget feeds; I rarely ever see this practise of sticking a major version in the package ID, but is there really any alternative?
There are many existing packages that uses the MVC version as part of their naming convention to differentiate between supported versions :
WindowsAzure.WebRole.MVC3
Unity.Mvc3
Spark.Web.Mvc2
Spark.Web.Mvc3
...
"Only problem with that is that it's then possible for someone to try and include both!"
I wouldn't bother trying to block this case, it would seem obvious by the name of the package that both are not meant to be side-by-side.