Cool. That makes sense. Thanks
On Sep 7, 2016 1:23 AM, "Sergey Grebnov (Akvelon)" <v-seg...@microsoft.com>
wrote:
> The reason Vladimir didn't specify CURRENT_PLUGIN_VERSION is that we know
> for sure that all plugins currently support Cordova 6.1.0 (version where we
> introduced cordovaDependencies logic) so adding this section is not
> necessary and has no effect. But if we add something like below this may
> confuse as people may incorrectly think that current plugin version won't
> work on 6.0.0 for example. So I think we should start specifying
> CURRENT_PLUGIN_VERSION restriction when it is really necessary.
>
> CURRENT_PLUGIN_VERSION: { cordova: >= 6.1.0 }
>
> Vladimir is on vacation next two weeks so I plan to complete his PRs
> tomorrow if there are no objections - please let me know.
>
> Thanks,
> Sergey
>
> -----Original Message-----
> From: Steven Gill [mailto:stevengil...@gmail.com]
> Sent: Friday, September 2, 2016 5:28 AM
> To: dev@cordova.apache.org
> Subject: Re: [PROPOSAL] Using cordovaDependencies in core plugins
>
> 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
> >
> >
>
