I have seen weird behaviour of attrs in odoo for all versions (v8, v9,v10).
I want to know the reason why odoo frameworks behaves like that.
I have listed domains for m2m fields / o2m fields which I have tested for all versions, why it's version specific ?
I have written Yes if the domain is working for that version otherwise written No.
Related
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.
I have a Mac "Shoebox" app that internally uses NSDocument objects, but does not expose the concept of individual documents to the user. (I rely on NSDocument to make syncing via iCloud easier.)
My problem is that when a version conflict arises, my app shows the default NSDocument conflict resolution alert (see below) letting the user pick one or two winners.
In the concept of my app this doesn't make sense. Is there a way to intercept/prevent that alert and handle the conflict programmatically?
I know that I can detect version conflicts with the code below. However, I still need to prevent the alert sheet.
[NSFileVersion unresolvedConflictVersionsOfItemAtURL:document.fileURL];
Example conflict resolution alert:
This is the built in behavior of NSDocument when it discovers there are unresolved version conflicts. If you do not wish to use it you'll have to drop support for NSDocument and use a lower level abstraction like NSFileManager + NSFileVersion.
You can override + (BOOL)usesUbiquitousStorage and return NO.
This will no longer show the ubiquity conflict panel.
See the doc Resolving Document Version Conflicts
Strategies for Resolving Document Version Conflicts
Your application can follow one of three strategies for resolving document-version conflicts:
Merge the changes from the conflicting versions.
Choose one of the
document versions based on some pertinent factor, such as the version
with the latest modification date.
Enable the user to view
conflicting versions of a document and select the one to use.
Which strategy is best to use depends a lot upon your document data. If you can merge the contents of different document versions without introducing contradictory elements, then follow that strategy. Or choose the document version with the latest modification date if your application doesn’t suffer any loss of data as a result.
Generally, you should try to resolve the conflict without involving the user, but for some applications that might not be possible. If an application takes the user-centered approach, it should discreetly inform the user about the version conflict and expose a button or other control that initiates the resolution procedure. An Example: Letting the User Pick the Version examines the code of an application that lets the user select the document version to use.
My client purchased a Joomla component, the comoponent need a customization in both front end and back end.
But his requirment is, custom code in front end and back end to be upgrded while upgrading original component.
Example : I bought a component from a company XYZ and the component name is joomla_events, current latest version is 2.0. I done the customization in the version 2.0. Later on the company releases new version 3.0, If the client upgrade the component from version2.0 to version 3.0 then the custom code in the version 2.0 also updated in version 3.0
Please help to do the custom code upgrade in Joomla component.
This is why editing core files is never recommended, because it gets overridden when updated and people then start to have problems.
A simple answer to your question is, you can't have the custom code you added into version 2.0 appear in version 3.0.
You will need to re-add the code you added before. Yes, it is pain taking and annoying, however you would have been better in the first place to develop a plugin which could have been used to extend the component and would make upgrading easy. Not only will you have to add your code again, but you will need to thoroughly test it to ensure it works.
check this may be it helps you....
http://docs.joomla.org/J2.5:Managing_Component_Updates_(Component_release_files)
I'm working on NopCommerce 2.60 and I have extended Affiliate Module in NopCommerce 2.6 by adding two new fields like "WebsiteURL" and "Picture Upload".
For that I have made changes in Affiliate Services, Affiliate Controller, Affiliate.cs, Affiliate Map, Affiliate Model files. Now If I want to integrate these changes in upcoming versions of NopCommerce.
So What is better way to make changes in NopCommerce code and easily integrate in upcoming versions of NopCommerce?
There is no any way in nopcommerce to upgrade custom functionality in higher version. instead of that i would suggest right you function independent to nop means write separate classes for all Affiliate functionality, copy it in next version as you see in nopcommerce2.65 they have change some service, properties name.
I have recently looked into this since our company wanted to make sure nopCommerce could be upgraded at later dates if needed. The best solution we found was to make our modifications into plugins so that we could refrain from modifying the core as much as possible. Like Shivkumar said, it's not really possible to make nopCommerce upgrade proof.
Hope this helps.
I am not even sure how to ask this question. I am absolutely willing to research this myself, but I don't even know what exactly my options are.
I'm fairly new to programming in general, and I'm the sole developer on an ASP.NET MVC3 web application. We're about to upgrade to a new version which has a lot of addition to the data model. There are a couple new entities and some of the old entities have new properties/columns.
We've finished beta testing and now we're going to try to get everyone moved over to the new version running parallel to the current version, that way if there are show-stopping problems, users can easily switch back to the old version. The problem is that we can't hook both up to the same db because of the data model differences.
Can I make the old version use the new version's schema or something? I'm not really sure what my options are. I'm not asking you to write this for me; I'm just looking for some direction. Thanks!
You should be able to disable the metadata checks and then use two versions against the DB assuming the models use a schema that is compatible between both.
http://revweblog.wordpress.com/2011/05/16/ef-4-1-code-first-disable-checking-for-edmmetadata-table/
Another option is to use entity framework 4.3 code first migrations and actually use an upgrade script that it will generate for you. If it fails you can roll back the script to a prior version and use your prior code base. This would imply you upgrade to 4.3 first before doing anything else though although you could still disable metadata checks.