Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 69CB310746 for ; Tue, 24 Feb 2015 02:54:22 +0000 (UTC) Received: (qmail 95523 invoked by uid 500); 24 Feb 2015 02:54:22 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 95484 invoked by uid 500); 24 Feb 2015 02:54:22 -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 95470 invoked by uid 99); 24 Feb 2015 02:54:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Feb 2015 02:54:21 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of agrieve@google.com designates 209.85.223.180 as permitted sender) Received: from [209.85.223.180] (HELO mail-ie0-f180.google.com) (209.85.223.180) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Feb 2015 02:54:17 +0000 Received: by iebtr6 with SMTP id tr6so28599715ieb.10 for ; Mon, 23 Feb 2015 18:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=cQqTlz87hYRNJzDM+gan9uOJMzusLXPePTiZI9F+s/I=; b=PsUG7dadPLCtCSIDEAgD1XcPelp4iRtmVlqq5IbyRNiR+rqmhKCYl3eYrRDVZRoJ7g hVzxcg64RQBa4CpttCkLwPfL8JtzSV9TLhPxjkM/rMmNeCo98+dOUp+80gYzqpDtphsX AsQBqC8P29p9a7YCnyRaFvgWUZVfRZmzbDgUb8i4aIalqnUHYVlul0BnsU7RumV4i7/m fQjH0y2GTilMf5ArFau8/jWKj2GsFg8W5NGueyFwXAheseCoxWXeczoeYzj9mjSlG6+N pdHRA4BVRI1ui0M5/6R4wEXIK8FgLiembioIbJTW1fdWm4dpE+guXZ0mgb114HU7vInv 35dA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=cQqTlz87hYRNJzDM+gan9uOJMzusLXPePTiZI9F+s/I=; b=XTnFc8vWD2E9npc0ENyta9Ml1NVaTSz8vU5m/LIUyM3eZJlh8j+Vdelx0pW/h1OwyC hzBX6nCzBABzq87SK/zWzfpHCsoE/m9jwW8ld8BrR/t160FE6Kj7JWNwSFNcbcJsk1zw 1NjMx3NRhxysN3A7z3MuXrjrmqjZo1qsgE/yM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=cQqTlz87hYRNJzDM+gan9uOJMzusLXPePTiZI9F+s/I=; b=PraUySIlq6BKWQLzfbgkU0tK0gUjUuFeWV8VBg8ikItvtYS0ablRTNvc9zECKT4P6X E6awAQkKTCPEY086DaiUFhVCtS0FyN+aBbP7kBGPTpGrTWKq9R4bgKcCA4GlWor6iVM0 bwtBUQZbFZa1w5AqcQWeaeCRNeGM5wfGHlIN1/QXPIdnMxRuPxWLLu0OydZ9fFJa5CrN yROo8g4CdD7BX75dmTMA/TJKJZh0if2B00dxmJ4UCtKsviavTBMRSIxzDslJt2P8Ni0b 0JT9DG2xFAVc67v2ogkb8LnA1U6H7/qHjp3pcZE5IOJQgcJ9ZzyVV1QNZAX/ybC1IDRC GvEA== X-Gm-Message-State: ALoCoQn4nTHQeWbPi/F7eyZiWm72tBE+78RyXJpcq0WAwa4R7GFnCe5foXfaPZBY61aDTEnDV5uJ X-Received: by 10.107.155.131 with SMTP id d125mr18320810ioe.17.1424746391134; Mon, 23 Feb 2015 18:53:11 -0800 (PST) MIME-Version: 1.0 Sender: agrieve@google.com Received: by 10.36.3.136 with HTTP; Mon, 23 Feb 2015 18:52:50 -0800 (PST) In-Reply-To: References: <2F4839DC-CD04-419B-A050-1EF61AA831A2@gmail.com> From: Andrew Grieve Date: Mon, 23 Feb 2015 21:52:50 -0500 X-Google-Sender-Auth: uZcNoJwstTGMUQn3i6NLuzJ49tw Message-ID: Subject: Re: Schedule for npm transition To: dev Cc: Michal Mocny Content-Type: multipart/alternative; boundary=001a1140aace8a11e6050fcc9e31 X-Virus-Checked: Checked by ClamAV on apache.org --001a1140aace8a11e6050fcc9e31 Content-Type: text/plain; charset=UTF-8 I suppose it's workable, but it seems worse than what we currently have. E.g. I don't care about Android, but npm peerDependencies will complain until I've installed the android.support.v4 plugin into my node_modules. On Mon, Feb 23, 2015 at 4:26 PM, Michal Mocny wrote: > I scanned the core plugins, and only contacts uses platform specific deps, > and only for 2 BB plugins. > > Also scanned the top 20 non-core plugins from CPR, and: > > - com.cranberrygame.phonegap.plugin.ad.admob > - depends on google-play-services only on android, but that plugin only > supports android. > - com.google.cordova.admob (Note: not published by com.google..) > - Same as above > - plugin.google.maps > - Same as above > - also depends on android.support.v4 for android only (but its also an > android only plugin) > - also depends on com.googlemaps.ios for ios only (but its an ios only > plugin) > - net.yoik.cordova.plugins.screenorientation > - Depends on com.blackberry.app only for BB (but its BB only plugin) > > > So.. this is not an uncommon use, but it seems unnecessary in all cases > I've found so far. > > -Michal > > On Mon, Feb 23, 2015 at 4:10 PM, Michal Mocny wrote: > > > > > > > On Mon, Feb 23, 2015 at 3:36 PM, Andrew Grieve > > wrote: > > > >> You can use plugin.xml to print a message upon installation. > >> > >> Plugins can specify dependencies on a per-platform basis. Don't think we > >> can capture this with package.json without using custom keys. > >> > > > > Do we need to? I mean, this is a breaking change, but perhaps once that > > is acceptable in practice. I.e. Contacts depends on > com.blackberry.utils, > > but that plugin only supports the BB and so shouldn't be > > installed on others. > > > > In theory there exists a plugin which supports all platforms but is only > > explicitly needed for one platform as a dependency.. But I don't know. > > Does the issue come up in practice? > > > > > >> > >> > >> > >> On Mon, Feb 23, 2015 at 2:42 PM, Michal Mocny > >> wrote: > >> > >> > On Mon, Feb 23, 2015 at 2:22 PM, Steven Gill > >> > wrote: > >> > > >> > > +1 to giving plugins major version bump > >> > > +1 to publishing old versions to npm > >> > > > >> > > Short term we can keep dependency tag using plugin ids. Wouldn't it > >> make > >> > > more sense long term to move those dependencies into package.json > >> file of > >> > > each plugin? > >> > > > >> > > >> > Probably peerDependencies not dependencies. I forgot about that.. > >> Indeed > >> > that was the plan. > >> > > >> > I think one current benefit of tag over package.json is > >> that > >> > the latter only guarantees that the plugins are downloaded, while the > >> > former guarantees that they are installed. We could update our tools > >> to do > >> > an install time check for a package.json and then scan the locally > >> > installed packages which are listed in its peerDependencies to see if > >> any > >> > are cordova plugins and install those automatically, but I'm not quite > >> sure > >> > thats the right voodoo.. > >> > > >> > Anyway, assuming we can come up with a sensible plan, I would rather > do > >> it > >> > all at once with the upcoming Major version bump. > >> > > >> > > >> > > >> > > > >> > > I am going to begin the process of adding package.json to all of our > >> > > plugins today and will look into publishing older versions to npm. > >> > > >> > > >> > > Third-party plugins can either keep their package-id as package-name > >> or > >> > > rename. It will be up to them. If they keep it, no need to send a PR > >> to > >> > > mapper module. If they decide on a new package-name, it is probably > in > >> > > their best interest to send a PR. > >> > > >> > > >> > Sounds good, though I'm hoping to provide guidance that renames are > >> better > >> > by doing it for core plugins. The need for the mapper is probably a > >> bit of > >> > an exaggeration anyway. Once CPR goes deprecated, we should start > >> warning > >> > that plugins should be fetched from npm. Users will then search for > the > >> > name of the npm package and the plugin author can rename freely by > just > >> > documenting accordingly. Once the CPR goes down, this will be even > more > >> > true. > >> > > >> > (Additionally, authors can publish a CPR plugin before CPR goes down > >> that > >> > has an install hook which says "This plugin has moved to npm under the > >> > name..". I'm less and less convinced the mapper is needed at all..) > >> > > >> > > >> > > >> > > >> > > > >> > > > >> > > > >> > > > >> > > On Thu, Feb 19, 2015 at 6:50 AM, Carlos Santana < > csantana23@gmail.com > >> > > >> > > wrote: > >> > > > >> > > > Lets consider to take this time and make our plugins 1.0.0 and > start > >> > > > following semver 2.0 more strict. The community is starting to > >> accept > >> > > that > >> > > > is ok if the major number is not zero, and a number means > something > >> > that > >> > > > can be use in production. > >> > > > I understand that people might have their own opinion on what is a > >> > MAJOR, > >> > > > meaning an API brake when the plugin is running on the device and > >> the > >> > API > >> > > > of the javascript API to the plugin. > >> > > > But I want to consider how a plugin is manage in terms of tooling, > >> > > > declaring and resolving dependencies, plugin.xml schema, > >> > > > browersify/bootstrapjs, we could say that this consider an API > for > >> the > >> > > > plugin. > >> > > > Another point is if the plugin are going to change in terms how > they > >> > are > >> > > > manage, we can take an opportunity to take the developers > attention > >> > with > >> > > > the major version number change to easy distinguish that there > >> > something > >> > > > new going with plugins since 1.0.0 and up. > >> > > > > >> > > > On Tue, Feb 17, 2015 at 4:02 PM, Chuck Lantz < > clantz@microsoft.com> > >> > > wrote: > >> > > > > >> > > > > I think the incident over the weekend pointed out that people > are > >> in > >> > > fact > >> > > > > pinning versions in plugin dependencies to avoid unexpected > >> > regressions > >> > > > or > >> > > > > in apps due to things like security reviews. (Ex: Each version > >> of a > >> > > > piece > >> > > > > of software that is published inside an app needs to go through > a > >> > legal > >> > > > > review at some companies.) So, I think it will be critical that > >> > people > >> > > > can > >> > > > > get back to older versions of plugins beyond the 3 + 6 = 9 month > >> CPR > >> > > > > window. Big time +1 to back publishing versions npm for that > >> reason > >> > > > unless > >> > > > > we intend to keep the CPR around for a long time. We also will > >> want > >> > to > >> > > > > tell plugin authors that they will want to do the same. (Note > >> that > >> > I'm > >> > > > > less worried about IDEs than I am app and plugin authors here.) > >> > > > > > >> > > > > > >> > > > > > >> > > > > What we're talking about so far has been around changing the > >> behavior > >> > > of > >> > > > > cordova-lib over this period. A few questions assuming we go > with > >> > > > having a > >> > > > > mapper module: > >> > > > > > >> > > > > > >> > > > > > >> > > > > 1. During and after the transition period, should we > >> recommend > >> > > that > >> > > > > 3rd party plugin authors contribute their IDs to the mapper > >> module to > >> > > > > maintain compat as the CPR shuts down if they want/need to > >> publish to > >> > > npm > >> > > > > with a different name? Is there a process we want to setup to > make > >> > this > >> > > > > easy? > >> > > > > > >> > > > > 2. What about apps using old versions of Cordova that > >> pre-date > >> > npm > >> > > > > support being present? Given it sounds like Nodejitsu will help > >> with > >> > > any > >> > > > > migration needed, is there an urgency to shut down the CPR > itself > >> > > > > (regardless of what cordova-lib itself does) in this time > window? > >> Or > >> > > are > >> > > > we > >> > > > > simply telling people they have to upgrade to install any new > >> > plugins? > >> > > > > > >> > > > > > >> > > > > > >> > > > > -Chuck > >> > > > > > >> > > > > > >> > > > > > >> > > > > -----Original Message----- > >> > > > > From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of > >> > Michal > >> > > > > Mocny > >> > > > > Sent: Tuesday, February 17, 2015 9:32 AM > >> > > > > To: dev > >> > > > > Subject: Re: Schedule for npm transition > >> > > > > > >> > > > > > >> > > > > > >> > > > > FYI since its perhaps relevant to npm transition (from npm > weekly > >> > > notes): > >> > > > > > >> > > > > > >> > > > > > >> > > > > "We will also be changing the behavior of peerDependencies in > >> npm@3. > >> > > We > >> > > > > won't be automatically downloading the peer dependency anymore. > >> > > Instead, > >> > > > > we'll warn you if the peer dependency isn't already installed. > >> This > >> > > > > requires you to resolve peerDependency conflicts yourself, > >> manually, > >> > > but > >> > > > in > >> > > > > the long run this should make it less likely that you'll end up > >> in a > >> > > > tricky > >> > > > > spot with your packages' dependencies." > >> > > > > > >> > > > > > >> > > > > > >> > > > > -Michal > >> > > > > > >> > > > > > >> > > > > > >> > > > > On Tue, Feb 17, 2015 at 12:13 PM, Andrew Grieve < > >> > agrieve@chromium.org > >> > > > > > > >> > > > > > >> > > > > wrote: > >> > > > > > >> > > > > > >> > > > > > >> > > > > > On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny < > >> > mmocny@chromium.org > >> > > > > > > >> > > > > > >> > > > > > wrote: > >> > > > > > >> > > > > > > >> > > > > > >> > > > > > > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > wrote: > >> > > > > > >> > > > > > > > >> > > > > > >> > > > > > > > Sorry to be dragging this out, but I think it's important > >> that > >> > > the > >> > > > > > >> > > > > > > > plan here is crystal clear. > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > On Wed, Feb 11, 2015 at 4:56 PM, Michal Mocny > >> > > > > > >> > > > > > > > > > >> > > > > > >> > > > > > > wrote: > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > > I would agree that we should change plugin ID as well as > >> > > package > >> > > > > > >> > > > > > name, > >> > > > > > >> > > > > > > > but > >> > > > > > >> > > > > > > > > I don't think that affects the results. > >> > > > > > >> > > > > > > > > > >> > > > > > >> > > > > > > > > All 3 of those use cases you mentioned I think are > >> addressed > >> > > > > > >> > > > > > > > equivalently. > >> > > > > > >> > > > > > > > > Whether the plugin is added as a dependency, with > >> > save/restore, > >> > > > > > >> > > > > > > > > or explicitly from the command line, cordova-lib would > >> first > >> > > > > > >> > > > > > > > > check if > >> > > > > > >> > > > > > > there > >> > > > > > >> > > > > > > > is > >> > > > > > >> > > > > > > > > a mapping from old ID -> new package name, or use what's > >> > given > >> > > > > > >> > > > > > > verbatim. > >> > > > > > >> > > > > > > > > So the only concern is with third party plugin authors > who > >> > > chose > >> > > > > > >> > > > > > > > > to > >> > > > > > >> > > > > > > > rename > >> > > > > > >> > > > > > > > > plugins, and already have dependants, and don't > register a > >> > > > > > >> > > > > > > > > mapping > >> > > > > > >> > > > > > with > >> > > > > > >> > > > > > > > us. > >> > > > > > >> > > > > > > > > > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > There is a runtime dependency on plugin ID. It's used when > >> > > > > > >> > > > > > > > require()ing other JS modules, and on Android it's used to > >> > access > >> > > > > > >> > > > > > > > the plugin's > >> > > > > > >> > > > > > native > >> > > > > > >> > > > > > > > side (pluginManager.getPlugin("ID")). > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > We could have a mapper that knows that I type "plugin add > >> "", > >> > to > >> > > > > > >> > > > > > > > fetch "cordova-plugin-file", but if we also change the > >> plugin > >> > ID, > >> > > > > > >> > > > > > > > then we'll > >> > > > > > >> > > > > > > get > >> > > > > > >> > > > > > > > runtime problems. So... if we have a mapper, then no > >> changing > >> > > > > > >> > > > > > > > plugin > >> > > > > > >> > > > > > IDs. > >> > > > > > >> > > > > > > > Correct? > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > >> > > > > > >> > > > > > > I agree at first, but after sleeping on it, perhaps this is > >> not > >> > > > > > >> > > > > > necessarily > >> > > > > > >> > > > > > > true. Perhaps changing plugin ID could just be a semver > >> breaking > >> > > > > change? > >> > > > > > >> > > > > > > Then, even if it was installed using old plugin-id and the > >> mapper > >> > > > > > >> > > > > > > mapped > >> > > > > > >> > > > > > to > >> > > > > > >> > > > > > > the npm package-name, any plugin compatible with this MAJOR > >> > version > >> > > > > > >> > > > > > > of > >> > > > > > >> > > > > > the > >> > > > > > >> > > > > > > plugin would know to use the new plugin id. > >> > > > > > >> > > > > > > > >> > > > > > >> > > > > > That'd probably work. In practice I haven't seen plugins pin > >> > versions > >> > > > > > >> > > > > > within , but they probably should. > >> > > > > > >> > > > > > > >> > > > > > >> > > > > > > >> > > > > > >> > > > > > > >> > > > > > >> > > > > > > > >> > > > > > >> > > > > > > For old versions of the plugin published to npm, we do have > to > >> > > leave > >> > > > > > >> > > > > > > the plugin id as-is. > >> > > > > > >> > > > > > > > >> > > > > > >> > > > > > > > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > Okay, so we don't change the plugin ID, just the package > >> name. > >> > > > > > >> > > > > > > > - When people use , they should still use > >> plugin ID > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > >> > > > > > >> > > > > > > Nit: why? (and config.xml ) should use > >> the > >> > > > > > >> > > > > > > same target as "cordova plugin add", which at this point > >> should > >> > > > > > >> > > > > > > change to package-name. If we do leave plugin-id different > >> from > >> > > > > > >> > > > > > > package-name, it should only be used internally by plugin > >> authors > >> > > > > > >> > > > > > > who depend on other plugins. > >> > > > > > >> > > > > > > > >> > > > > > >> > > > > > > >> > > > > > >> > > > > > "plugin add" can take git URLs, local directory paths. > >> >> > > > > > >> > > > > > id="" /> is pretty clear that it's an ID, and in this form it > >> > doesn't > >> > > > > > >> > > > > > specify where to get the plugin from > >> > > > > > >> > > > > > > >> > > > > > >> > > > > > The logic for dependency in plugman is to: > >> > > > > > >> > > > > > 1. Fetch it (e.g. use search paths, or find-by-id from the > >> > > registry). > >> > > > > > >> > > > > > 2. Validate that the plugin.xml we fetched matches the ID from > >> > > > > > >> > > > > > 3. Install it > >> > > > > > >> > > > > > > >> > > > > > >> > > > > > I don't think we can do the validation step if we allow > >> > package-name > >> > > > > > >> > > > > > within . Plus, except for core plugins that have a > >> > > mapper, > >> > > > > > >> > > > > > you couldn't do the search-path logic correctly without the > >> plugin > >> > > ID. > >> > > > > > >> > > > > > > >> > > > > > >> > > > > > > >> > > > > > >> > > > > > > >> > > > > > >> > > > > > > >> > > > > > >> > > > > > > > >> > > > > > >> > > > > > > > >> > > > > > >> > > > > > > > - If they "cordova plugin add", we'll allow them to > specify > >> NPM > >> > > > > > >> > > > > > > > package name *or* plugin ID. > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > >> > > > > > >> > > > > > > Possibly only support plugin-id for some deprecation time? > >> > (Though > >> > > > > > >> > > > > > > if we publish old versions to npm, maybe we just leave it > >> > supported > >> > > > > > >> > > > > > > + warning > >> > > > > > >> > > > > > > always) > >> > > > > > >> > > > > > > > >> > > > > > >> > > > > > > - We'd use the reverse-mapping so that plugin search path > will > >> > work > >> > > > > > >> > > > > > > if > >> > > > > > >> > > > > > they > >> > > > > > >> > > > > > > > specify package name. > >> > > > > > >> > > > > > > > - E.g. "cordova plugin add cordova-plugin-file", will > >> need to > >> > > > > > >> > > > > > > > know to scan search-path directories for > >> > > "org.apache.cordova.file". > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > >> > > > > > >> > > > > > > Indeed! > >> > > > > > >> > > > > > > > >> > > > > > >> > > > > > > > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > I think the different-IDs-than-package-name approach will > >> work, > >> > > > > > >> > > > > > > > but I > >> > > > > > >> > > > > > > think > >> > > > > > >> > > > > > > > it's too much of a hassle to be used by third-party > plugins, > >> > > > > > >> > > > > > > > because > >> > > > > > >> > > > > > it's > >> > > > > > >> > > > > > > > more work to have the names be different: > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > >> > > > > > >> > > > > > > I tend to agree. I think it *could* work, but we should > think > >> > > > > > >> > > > > > > through if it is necessary. > >> > > > > > >> > > > > > > > >> > > > > > >> > > > > > > > >> > > > > > >> > > > > > > > - If their ID is the same as the package name: > >> > > > > > >> > > > > > > > - They fit in more naturally with NPM > >> > > > > > >> > > > > > > > - The fetching logic will be faster (since we know we > >> don't > >> > > > > > >> > > > > > > > need to check CPR first) > >> > > > > > >> > > > > > > > - They don't need to send a pull request and wait for a > >> > > release > >> > > > > > >> > > > > > > > so > >> > > > > > >> > > > > > > that > >> > > > > > >> > > > > > > > people can install their plugin (mapper) > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > If third-parties don't opt into having different package > >> names > >> > > > > > >> > > > > > > > from > >> > > > > > >> > > > > > > plugin > >> > > > > > >> > > > > > > > IDs, then down the road the only plugins that will be in > >> this > >> > > > > > >> > > > > > > > state are > >> > > > > > >> > > > > > > the > >> > > > > > >> > > > > > > > core plugins. Maybe that's fine? > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > > I believe the only real question is: do we prefer a > >> minimally > >> > > > > > >> > > > > > > > > easier transition by leaving all names as they are, or > do > >> we > >> > > > > > >> > > > > > > > > prefer to have package names on npm that don't look out > of > >> > > place. > >> > > > > > >> > > > > > > > > > >> > > > > > >> > > > > > > > > I think any argument that there is a technical > preference > >> for > >> > > > > > >> > > > > > > > > one way > >> > > > > > >> > > > > > > > over > >> > > > > > >> > > > > > > > > the other hasn't really held up (but now would be a > great > >> > time > >> > > > > > >> > > > > > > > > to > >> > > > > > >> > > > > > > mention > >> > > > > > >> > > > > > > > > if that isn't true). > >> > > > > > >> > > > > > > > > > >> > > > > > >> > > > > > > > > (Note: choosing leaving names as they are still only > >> > guarantees > >> > > > > > >> > > > > > > > > core plugins do this, 3rd party authors may not > >> re-publish at > >> > > > > > >> > > > > > > > > all, or > >> > > > > > >> > > > > > rename > >> > > > > > >> > > > > > > > > however they want) > >> > > > > > >> > > > > > > > > > >> > > > > > >> > > > > > > > > -Michal > >> > > > > > >> > > > > > > > > > >> > > > > > >> > > > > > > > > On Wed, Feb 11, 2015 at 4:07 PM, Andrew Grieve > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > >> > > > > > >> > > > > > > > > wrote: > >> > > > > > >> > > > > > > > > > >> > > > > > >> > > > > > > > > > Going to try and summarize my concerns with the > proposal > >> > > here: > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > On Wed, Feb 11, 2015 at 2:39 PM, Steven Gill < > >> > > > > > >> > > > > > stevengill97@gmail.com > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > > > wrote: > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > > Correct! For the first 3 months, all requests will > hit > >> > CPR > >> > > > > > >> > > > > > > > > > > first, > >> > > > > > >> > > > > > > if > >> > > > > > >> > > > > > > > > CPR > >> > > > > > >> > > > > > > > > > > fails, we will try to fetch from npm. > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > > If users run "cordova plugin add > >> cordova-plugin-device", > >> > it > >> > > > > > >> > > > > > > > > > > would > >> > > > > > >> > > > > > > hit > >> > > > > > >> > > > > > > > > > CPR, > >> > > > > > >> > > > > > > > > > > fail, go to npm, succeed. > >> > > > > > >> > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > CPR doesn't allow non-reverse dns names. There'd be no > >> > reason > >> > > > > > >> > > > > > > > > > to > >> > > > > > >> > > > > > > check > >> > > > > > >> > > > > > > > it > >> > > > > > >> > > > > > > > > > unless the name had at least 2 periods in it. > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > If we're not using package names to detect which > >> registry > >> > to > >> > > > > > >> > > > > > > > > > use, I > >> > > > > > >> > > > > > > > don't > >> > > > > > >> > > > > > > > > > actually see any benefit in changing names. > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > If we use the mapper module, "cordova plugin add > >> > > > > > >> > > > > > > > > > > org.apache.cordova.device" would be converted to > >> > > > > > >> > > > > > > > cordova-plugin-device, > >> > > > > > >> > > > > > > > > > hit > >> > > > > > >> > > > > > > > > > > CPR, fail, go to npm, succeed. > >> > > > > > >> > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > While this works fine for our modules, I don't think > >> it'll > >> > > > > > >> > > > > > > > > > work > >> > > > > > >> > > > > > well > >> > > > > > >> > > > > > > > for > >> > > > > > >> > > > > > > > > > others'. Three use-cases for them: > >> > > > > > >> > > > > > > > > > 1. within plugin.xml. > >> > > > > > >> > > > > > > > > > 2. within config.xml (for cordova plugin > >> restore). > >> > > > > > >> > > > > > > > > > 3. cordova plugin add FOO > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > All three would be solved if we enforce that > >> packageName == > >> > > > > > >> > > > > > pluginId. > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > I think we should either: > >> > > > > > >> > > > > > > > > > - publish under npm under our existing IDs > >> > > > > > >> > > > > > > > > > or: > >> > > > > > >> > > > > > > > > > - publish under npm under cordova-plugin-FOO, and > change > >> > > > > > >> > > > > > > > > > plugin IDs > >> > > > > > >> > > > > > > to > >> > > > > > >> > > > > > > > be > >> > > > > > >> > > > > > > > > > cordova-plugin-FOO > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > After 3 months, "cordova plugin add > >> > cordova-plugin-device" > >> > > > > > >> > > > > > > > > > > would > >> > > > > > >> > > > > > > hit > >> > > > > > >> > > > > > > > > npm > >> > > > > > >> > > > > > > > > > > first and succeed. > >> > > > > > >> > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > We want to use these 3 months to get our developers > to > >> > > > > > >> > > > > > > > > > > update > >> > > > > > >> > > > > > their > >> > > > > > >> > > > > > > > > tools > >> > > > > > >> > > > > > > > > > > and use the new names for plugins to install. > >> > > > > > >> > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > On Wed, Feb 11, 2015 at 10:36 AM, Michal Mocny < > >> > > > > > >> > > > > > > mmocny@chromium.org> > >> > > > > > >> > > > > > > > > > > wrote: > >> > > > > > >> > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > Steve, npm fetch default only affects plugins that > >> use > >> > > > > > >> > > > > > > > > > > > same > >> > > > > > >> > > > > > name > >> > > > > > >> > > > > > > in > >> > > > > > >> > > > > > > > > > both > >> > > > > > >> > > > > > > > > > > > places, right? > >> > > > > > >> > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > If we create cordova-plugin-device today, and tell > >> > users > >> > > > > > >> > > > > > > > > > > > to > >> > > > > > >> > > > > > start > >> > > > > > >> > > > > > > > > using > >> > > > > > >> > > > > > > > > > > > cordova plugin add cordova-plugin-device, then we > >> will > >> > > get > >> > > > > > >> > > > > > > > > > > > much > >> > > > > > >> > > > > > > > user > >> > > > > > >> > > > > > > > > > > > feedback on npm fetching far before May 18th, > right? > >> > > > > > >> > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > On Wed, Feb 11, 2015 at 1:09 PM, Steven Gill < > >> > > > > > >> > > > > > > > stevengill97@gmail.com > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > wrote: > >> > > > > > >> > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > > We don't have one yet but we should pick dates > >> soon. > >> > > > > > >> > > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > > How about: > >> > > > > > >> > > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > > CPR Switch to read only: Monday, May 18th NPM > >> fetch > >> > > > > > >> > > > > > > > > > > > > becomes default: Monday, May 18th CPR offline: > >> > Monday, > >> > > > > > >> > > > > > > > > > > > > August 17th > >> > > > > > >> > > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > > Based on the following proposal: > >> > > > > > >> > > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > >> > > > > > >> > > > > > > >> > > > >> https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP- > >> > > > > > >> > > > > > 9DpYkcmfs/edit?usp=sharing > >> > > > > > >> > > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > > - Need to start educating plugin developers to > >> > publish > >> > > > > > >> > > > > > > > > > > > > to > >> > > > > > >> > > > > > npm > >> > > > > > >> > > > > > > as > >> > > > > > >> > > > > > > > > > well > >> > > > > > >> > > > > > > > > > > as > >> > > > > > >> > > > > > > > > > > > > CPR for next three months. (blog post) > >> > > > > > >> > > > > > > > > > > > > - Need to educate users to install plugins via > >> new > >> > > > > > >> > > > > > > > > > > > > names (if > >> > > > > > >> > > > > > > > > > > > package-name > >> > > > > > >> > > > > > > > > > > > > is different than id). Our core plugins are > being > >> > > > > > >> > > > > > > > > > > > > renamed > >> > > > > > >> > > > > > from > >> > > > > > >> > > > > > > > > > > > > org.apache.cordova.device to > cordova-plugin-device > >> > > > > > >> > > > > > > > > > > > > - Inform devs who are working with registry > >> directly > >> > to > >> > > > > > >> > > > > > > > > > > > > pull > >> > > > > > >> > > > > > > > > plugins > >> > > > > > >> > > > > > > > > > > from > >> > > > > > >> > > > > > > > > > > > > npm instead of CPR. After 3 months, CPR plugins > >> will > >> > > > > > >> > > > > > > > > > > > > start to > >> > > > > > >> > > > > > > > > become > >> > > > > > >> > > > > > > > > > > out > >> > > > > > >> > > > > > > > > > > > of > >> > > > > > >> > > > > > > > > > > > > date compared to npm versions. > >> > > > > > >> > > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > > Our next plugins release (after the one > currently > >> > > > > > >> > > > > > > > > > > > > ongoing) > >> > > > > > >> > > > > > will > >> > > > > > >> > > > > > > > be > >> > > > > > >> > > > > > > > > > > > > published to npm as well as cpr. > >> > > > > > >> > > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > > On Wed, Feb 11, 2015 at 9:10 AM, Gorkem Ercan < > >> > > > > > >> > > > > > > > > > gorkem.ercan@gmail.com >> > >> > > > > > >> > > > > > > > > > > > > wrote: > >> > > > > > >> > > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > > > Is there a determined calendar for the npm > move > >> of > >> > > the > >> > > > > > >> > > > > > > plugins? > >> > > > > > >> > > > > > > > > > > > > > I think the scheduling of the transition is > >> crucial > >> > > > > > >> > > > > > > > > > > > > > for > >> > > > > > >> > > > > > those > >> > > > > > >> > > > > > > > who > >> > > > > > >> > > > > > > > > > are > >> > > > > > >> > > > > > > > > > > > > > using the plugin registry directly. > >> > > > > > >> > > > > > > > > > > > > > -- > >> > > > > > >> > > > > > > > > > > > > > Gorkem > >> > > > > > >> > > > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > > >> > --------------------------------------------------------------------- > >> > > > > > >> > > > > > > > > > > > > > To unsubscribe, e-mail: > >> > > > > > >> > > > > > > > > > > > > > dev-unsubscribe@cordova.apache.org >> > > > > dev-unsubscribe@cordova.apache.org> > >> > > > > > >> > > > > > > > > > > > > > For additional commands, e-mail: > >> > > > > > >> > > > > > dev-help@cordova.apache.org dev-help@cordova.apache.org> > >> > > > > > >> > > > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > >> > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > -- > >> > > > Carlos Santana > >> > > > > >> > > > > >> > > > >> > > >> > > > > > --001a1140aace8a11e6050fcc9e31--