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 mmocny@google.com designates
 209.85.220.180 as permitted sender)
MIME-Version: 1.0
Sender: mmocny@google.com
In-Reply-To: 
 <CAEeF2TeZgEFL8TAFqaXQzQFTX6a1yJ37UTz006bPWNipUM8e9w@mail.gmail.com>
References: <2F4839DC-CD04-419B-A050-1EF61AA831A2@gmail.com>
 <CAMSbhBi=2G5Q=AQ-wKJryBnfe+iNM28kkMKd9d9Dexo+5ZhKJQ@mail.gmail.com>
 <CAEeF2Td4V05HhTK2kVSnGsKJNL8bZTigknc-=h0Dvo9PBA1Oaw@mail.gmail.com>
 <CAMSbhBgRU1xtfbUethxR_Vz1ScWJh+d0+C_DmR30BS83pzXnxg@mail.gmail.com>
 <CABiQX1XGvRkh55RUYbUATN-EMCUdfofYgDWkihzi6vo=6sSHSQ@mail.gmail.com>
 <CAEeF2Td5M2QezDv=JFPrd-MHNs8aWt+hqA02MiOq0U-SLYesCw@mail.gmail.com>
 <CABiQX1XiZY+Oo1Dsb85zswPsSdhtLhmg+yOKD+kCif0+g4JHcg@mail.gmail.com>
 <CAEeF2TdGCW83RNJKS7QkbBmpG=tU=xJPUoSZRdsfEqXogyA0hg@mail.gmail.com>
 <CABiQX1Xy0r4KbSozj_VG-HEMbELXjKTjz6pCxfB5nedNAZ7w=A@mail.gmail.com>
 <CAEeF2TecN_-vhOxAfw_gDWTV6M2T_Egnvo7P4HDza7NgUvr04Q@mail.gmail.com>
 <BLUPR03MB065B85323BFE26AAC09C535CF2F0@BLUPR03MB065.namprd03.prod.outlook.com>
 <CAHYtTqk+89GqmCUmAFyqxHd8RuU=2QZ6pR_b03UgpfpxUnjkqw@mail.gmail.com>
 <CAMSbhBhJDwpUgMoRNrLQc6qr-LrCGryMEp5UB=4A61t2L4pCUw@mail.gmail.com>
 <CAEeF2TegSiY4Oixjvqrsr0gzHjKQ82_YeWgZ_Vd7CB5Pd_DWUg@mail.gmail.com>
 <CABiQX1V-qVP5XOeczq6ZXKDVSL7au5Rz7DDT7C8NLV-yOYQ96Q@mail.gmail.com>
 <CAEeF2TeZgEFL8TAFqaXQzQFTX6a1yJ37UTz006bPWNipUM8e9w@mail.gmail.com>
From: Michal Mocny <mmocny@chromium.org>
Date: Mon, 23 Feb 2015 16:26:21 -0500
Message-ID: 
 <CAEeF2TdqQX-hFxNdBUK+FT2UYgPY_GD2NRpSmC93PS_m2KP-eA@mail.gmail.com>
Subject: Re: Schedule for npm transition
To: Michal Mocny <mmocny@chromium.org>
Cc: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=bcaec502d86ee9eec2050fc80e2c

--bcaec502d86ee9eec2050fc80e2c
Content-Type: text/plain; charset=UTF-8

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 <mmocny@chromium.org> wrote:

>
>
> On Mon, Feb 23, 2015 at 3:36 PM, Andrew Grieve <agrieve@chromium.org>
> wrote:
>
>> You can use plugin.xml <info> 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 <platform> 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 <mmocny@chromium.org>
>> wrote:
>>
>> > On Mon, Feb 23, 2015 at 2:22 PM, Steven Gill <stevengill97@gmail.com>
>> > 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 <dependency> 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
>> > > > > <mailto:agrieve@chromium.org>>
>> > > > >
>> > > > > wrote:
>> > > > >
>> > > > >
>> > > > >
>> > > > > > On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny <
>> > mmocny@chromium.org
>> > > > > <mailto:mmocny@chromium.org>>
>> > > > >
>> > > > > > wrote:
>> > > > >
>> > > > > >
>> > > > >
>> > > > > > > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve
>> > > > >
>> > > > > > > <agrieve@chromium.org<mailto:agrieve@chromium.org>>
>> > > > >
>> > > > > > > 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
>> > > > >
>> > > > > > > > <mmocny@chromium.org<mailto:mmocny@chromium.org>>
>> > > > >
>> > > > > > > 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 <dependency>, 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 <dependency>, they should still use
>> plugin ID
>> > > > >
>> > > > > > > >
>> > > > >
>> > > > > > >
>> > > > >
>> > > > > > > Nit: why?  <dependency> (and config.xml <plugin>) 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.
>> <dependency
>> > > > >
>> > > > > > 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
>> > > > >
>> > > > > > <dependency> 3. Install it
>> > > > >
>> > > > > >
>> > > > >
>> > > > > > I don't think we can do the validation step if we allow
>> > package-name
>> > > > >
>> > > > > > within <dependency>. 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
>> > > > >
>> > > > > > > > > <agrieve@chromium.org
>> > > > >
>> > > > > > >
>> > > > >
>> > > > > > > > > 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<mailto: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. <dependency> within plugin.xml.
>> > > > >
>> > > > > > > > > > 2. <plugin> 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<mailto: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<mailto: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<mailto: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<mailto:
>> > > > > dev-unsubscribe@cordova.apache.org>
>> > > > >
>> > > > > > > > > > > > > > For additional commands, e-mail:
>> > > > >
>> > > > > > dev-help@cordova.apache.org<mailto:dev-help@cordova.apache.org>
>> > > > >
>> > > > > > > > > > > > > >
>> > > > >
>> > > > > > > > > > > > > >
>> > > > >
>> > > > > > > > > > > > >
>> > > > >
>> > > > > > > > > > > >
>> > > > >
>> > > > > > > > > > >
>> > > > >
>> > > > > > > > > >
>> > > > >
>> > > > > > > > >
>> > > > >
>> > > > > > > >
>> > > > >
>> > > > > > >
>> > > > >
>> > > > > >
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Carlos Santana
>> > > > <csantana23@gmail.com>
>> > > >
>> > >
>> >
>>
>
>

--bcaec502d86ee9eec2050fc80e2c--