[
https://issues.apache.org/jira/browse/CB-11795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473266#comment-15473266
]
ASF GitHub Bot commented on CB-11795:
-------------------------------------
Github user asfgit closed the pull request at:
https://github.com/apache/cordova-plugin-file-transfer/pull/157
> 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
