Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 555CC200B3E for ; Wed, 7 Sep 2016 16:39:09 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 53D93160AC1; Wed, 7 Sep 2016 14:39:09 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 70CDB160ABF for ; Wed, 7 Sep 2016 16:39:08 +0200 (CEST) Received: (qmail 8821 invoked by uid 500); 7 Sep 2016 14:39:07 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 8803 invoked by uid 99); 7 Sep 2016 14:39:07 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Sep 2016 14:39:07 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id CB689C0972 for ; Wed, 7 Sep 2016 14:39:06 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 4.526 X-Spam-Level: **** X-Spam-Status: No, score=4.526 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=2.397, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx2-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id GaND7Ur5y_Ew for ; Wed, 7 Sep 2016 14:39:04 +0000 (UTC) Received: from mail-yw0-f178.google.com (mail-yw0-f178.google.com [209.85.161.178]) by mx2-lw-eu.apache.org (ASF Mail Server at mx2-lw-eu.apache.org) with ESMTPS id 8A3DC5F5A1 for ; Wed, 7 Sep 2016 14:39:03 +0000 (UTC) Received: by mail-yw0-f178.google.com with SMTP id j1so10103358ywb.2 for ; Wed, 07 Sep 2016 07:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=kaVHbdV3aGOEY+5uAL5g+3zLsWub0CZCuQ7+m/4WJ40=; b=XRJVrQ2XIsC84qD/fAgGCAV+peKGNq3Wq6BDh4CTrCnoXpgt+W/aRYmPKA9kXmHX75 Mzva3TjydYF3hFPi/95LZKgZUJcu34vbHQ3ZxyKHvSopMnCwQKt74mn0zs1qVNNhfAWi 0wKbgr0iTEBz91OFfAfSs7aiA4CoSZlVObRayWVdMsugmOstrKeoOTZny0elEljhg5E6 YqtpyJ6kq/T/SG41nH2xkvZH2Jf5sRPqXb1S2pqBroRPsar4gEjebcv+ONIcLNciktCI UtlIwnpT6W2Wg0QlhpB7AarUPiYAicOswyO4aZVPAlvTe4HEJiCdIPGBLj9roWkc/Aqc h1Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=kaVHbdV3aGOEY+5uAL5g+3zLsWub0CZCuQ7+m/4WJ40=; b=D3g9r4bfzH1F4HoRl8x/3AZPT28Fh7wWXuq5llCqwURnd0rJVbCuS3zqvO1KZGjMHi I/0s6vOhQ+VhcPVN90ktoUqge/uATQGD5bMHo+zd2pg+/b3QhrmtYzB5hixn0jXMDQQP qVdvKuBunB6oqbSZpfESZ8BCNU1iWXDvzcYgSigF712d/10TZBJvpk1ESFwDOkGfjF1h eI+cZOCNEVHESNexOT7Fd8dMVX6tZxZxrxAT+vcYX3/2w/M8j1unIbSi/WN79OED4Tgb ajSazZhkCQiyV2Z82aCl7mEdkyHaoceCY8Y+mEU5Kfy5BlQKUT7ofbDmNkr7Sb/quD7Y x1xQ== X-Gm-Message-State: AE9vXwNRZjBd/4vstZarSfXUmF4mPu6hCua7oOsiecQMfgfbwaiS0TUvYD+xB9WIr4DLRYsPuvEMGVCmb18KuA== X-Received: by 10.13.231.3 with SMTP id q3mr36444870ywe.242.1473259142395; Wed, 07 Sep 2016 07:39:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.203 with HTTP; Wed, 7 Sep 2016 07:39:01 -0700 (PDT) Received: by 10.37.52.203 with HTTP; Wed, 7 Sep 2016 07:39:01 -0700 (PDT) In-Reply-To: References: From: Steven Gill Date: Wed, 7 Sep 2016 07:39:01 -0700 Message-ID: Subject: RE: [PROPOSAL] Using cordovaDependencies in core plugins To: dev@cordova.apache.org Content-Type: multipart/alternative; boundary=94eb2c080504d8530e053bebdfc1 archived-at: Wed, 07 Sep 2016 14:39:09 -0000 --94eb2c080504d8530e053bebdfc1 Content-Type: text/plain; charset=UTF-8 Cool. That makes sense. Thanks On Sep 7, 2016 1:23 AM, "Sergey Grebnov (Akvelon)" 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:stevengill97@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-vlkoti@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-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 > > > > > --94eb2c080504d8530e053bebdfc1--