cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Kotikov (Akvelon)" <v-vlk...@microsoft.com>
Subject RE: [PROPOSAL] Using cordovaDependencies in core plugins
Date Thu, 01 Sep 2016 13:33:33 GMT
No feedback has been received, so I assume it's a lazy consensus.
In continuation of this proposal I have opened a bunch of PRs to core plugins and going to
merge them by the end of this week if there are no objections.

-
Best regards, Vladimir

-----Original Message-----
From: Vladimir Kotikov (Akvelon) [mailto:v-vlkoti@microsoft.com] 
Sent: Friday, August 26, 2016 3:25 PM
To: dev@cordova.apache.org
Subject: [PROPOSAL] Using cordovaDependencies in core plugins

Hey all

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 our core plugins in a following way:

1. For every plugin we maintain, we add `cordovaDependencies` to its' package.json w/ the
following entry

    CURRENT_PLUGIN_VERSION: { cordova: >= LATEST_SUPPORTED_CORDOVA_VERSION }

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.

2. For every plugin we add additional 'protective' entry
  
    NEXT_MAJOR_PLUGIN_VERSION: { cordova: >= 100 }
  
  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 `ANOTHER_NEXT_MAJOR_PLUGIN_VERSION: { cordova:
>= 100 }` entry.

I would love to hear any feedback about this proposal or any other ideas that might help us
to prevent such breakages w/ cordova and plugins.

-
Best regards, Vladimir


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


Mime
View raw message