Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of braden@google.com designates
 209.85.216.43 as permitted sender)
MIME-Version: 1.0
Sender: braden@google.com
In-Reply-To: <20140206161243.6680725.93948.11350@blackberry.com>
References: <20140206161243.6680725.93948.11350@blackberry.com>
Date: Thu, 6 Feb 2014 11:21:47 -0500
Message-ID: 
 <CAMk5LLmrOu4FVkcspvxJ=4eVFipn5TgCMYT1Hn9deG7HXrNC6g@mail.gmail.com>
Subject: Re: Platform update and breaking plug-ins
From: Braden Shepherdson <braden@chromium.org>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a113ab29e24449204f1bf45e5

--001a113ab29e24449204f1bf45e5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I continue to feel that the right approach to platform updates is mostly to
keep making platforms/ a build artifact, and largely plugins/ too.

I feel that the right thing for an app developer to do for updating
platforms would be to backup the entire project, empty out platforms/ and
plugins/, and add them both back.

What I'd really like is for them to `cordova create ...`, copy in
config.xml and www/, `cordova platform add ...`, `cordova plugin add
--from-config`, and off you go. If there's nothing project-specific in
those directories, then they can be replaced as above.

Note that `plugin add --from-config` doesn't exist, but I'd like it to, so
that you can easily install plugins which are listed in your (top-level)
config.xml. Then you can specify version constraints, like >=3D 2.4 && < 3,
which will (assuming we semver properly) prevent you from picking up any
broken changes until you're ready to do so.

Of course I'm speaking normatively about what I'd like to see; the current
upgrade situation is quite a bit uglier.

Braden


On Thu, Feb 6, 2014 at 11:12 AM, Josh Soref <jsoref@blackberry.com> wrote:

> So, we discovered that a number of plugins are misusing an API in our
> platform (exec). We changed the implementation, and this broke the plug-i=
ns
> which were expecting different but not promised behavior.
>
> There's a cordova-cli platform update command, which is supposed to updat=
e
> your platform, but it doesn't seem fair consider whether a platform could
> be incompatible with a plug-in.
>
> I'm considering having platform update have a way to check the installed
> plugins and fail if they fit certain criteria. Does anyone have an opinio=
n
> on this?
>
> Another approach would be for the platform update command to be able to
> automatically update plugins (it should update them first, ideally to a
> version compatible with both the old and new platform ; if it plans to
> update after the platform and it's interrupted, then you can easily end u=
p
> with broken plugins).
>
> There is a before platform update hook available - although it isn't
> documented at:
> =E2=80=8E
> https://github.com/apache/cordova-cli/blob/master/templates/hooks-README.=
md
>
> I will file a bug and patch for this...
> I don't think that it would help. It would require a plug-in to know in
> advance that it's buggy, which is unlikely. Knowing about bugs is more th=
e
> job of a registry (plugins.cordova.io?)
>
> Sent from my BlackBerry 10 smartphone on the Bell network.
>
>

--001a113ab29e24449204f1bf45e5--