[ https://issues.apache.org/jira/browse/CB-11795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sergey Grebnov resolved CB-11795. --------------------------------- Resolution: Done > Introduce cordovaDependencies to all core plugins > ------------------------------------------------- > > Key: CB-11795 > URL: https://issues.apache.org/jira/browse/CB-11795 > Project: Apache Cordova > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: AllPlugins > Reporter: Vladimir Kotikov > Assignee: Vladimir Kotikov > Labels: triaged > > We've been researching ways to prevent cordova workflow breakages, caused by > installing edge versions of the plugins, which possibly could be incompatible > with cordova version, used by user. This is IMO a very nasty sort of > problems, because it might cause unpredictable build- and runtime failures of > cordova setup which has been working perfectly previously. > A typical example of this scenario is when some plugin introduces a change > incompatible w/ some particular cordova version and doesn't update > {{cordovaDependencies}} property in its' package.json correspondingly. > To prevent such breakages and avoid negative user experience I propose to > start using {{cordovaDependencies}} in core plugins in a following way: > # For every plugin we maintain, we add `cordovaDependencies` to its' > package.json w/ the following entry > {noformat} > CURRENT_PLUGIN_VERSION: { cordova: >= LATEST_SUPPORTED_CORDOVA_VERSION } > {noformat} > We will try to determine the {{LATEST_SUPPORTED_CORDOVA_VERSION}} based on > release > notes and most significant changes in plugins, but probably we can safely use > 6.1.0 here because new version choosing logic for {{plugin add}} was > introduced in this version and older versions of cordova will not use > {{cordovaDependencies}} anyway. > Also for some plugins adding such entry doesn't make sense because they will > work with any version of cordova, so for these plugins this step could be > omitted. > # For every plugin we add additional 'protective' entry > {noformat} > NEXT_MAJOR_PLUGIN_VERSION: { cordova: >= 100 } > {noformat} > There are 2 purposes for this: > - if there is a major plugin update that potentially would broke > compatibility > with some cordova versions, this will protect users against installing this > major update, unless plugin maintainers update `cordovaDependencies` by adding > corresponding entry for this plugin version. > In other words, if we've introduced a breaking change and forgot to > update {{cordovaDependencies}} correspondingly to reflect that the change > requires a specific cordova version, user will not get this plugin update. > - By some reason without such 'protective' entry in case if > {{NEXT_MAJOR_PLUGIN_VERSION}} gets released without adding corresponding > entry to {{cordovaDependencies}} (i.e. we don't have any restrictions for > this version in {{cordovaDependencies}}) - cordova will fetch that version > without any checks. > This is sounds non-obviously for me and probably there is some reason behind > installing plugin version, which we can't verify requirements for, but this > is how it works. > 3. When we introduce a change that requires us to change plugin version to > {{NEXT_MAJOR_PLUGIN_VERSION}}, we go and fix {{cordovaDependencies}} by > changing > cordova requirement for {{NEXT_MAJOR_PLUGIN_VERSION}} to actual value instead > of 100 and introducing > {noformat} > ANOTHER_NEXT_MAJOR_PLUGIN_VERSION: { cordova: >= 100 }}} > {noformat} > entry. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org