So to confirm, the idea is that all of our plugins will have a fake entry for the next major version of that plugin that only supports some future non existing version of cordova.
It forces us to update the cordovaDependencies field of a plugin when either a new major of the plugin comes out. In regards to your PRs, why not add a engine element for existing support? Seems like you are only adding NEXT_MAJOR_PLUGIN_VERSION but not CURRENT_PLUGIN_VERSION. https://github.com/apache/cordova-plugin-file/pull/194/files On Thu, Sep 1, 2016 at 6:33 AM, Vladimir Kotikov (Akvelon) < v-vlk...@microsoft.com> wrote: > 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-vlk...@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-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
