cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Schedule for npm transition
Date Wed, 25 Feb 2015 20:37:31 GMT
On Wed, Feb 25, 2015 at 3:08 PM, Steven Gill <stevengill97@gmail.com> wrote:

> All versions of released core plugins have been published to npm.
> https://issues.apache.org/jira/browse/CB-8529
> All our core plugins now have a package.json file.
> https://issues.apache.org/jira/browse/CB-8538
>
> A few of us from Adobe met with NPM yesterday. Summary:
>
> - Migration
>     - Use 'ecosystem:cordova' as a keyword in plugins for discoverability
> (instead of 'cordovaplugin'). I updated createpackagejson already with this.
>     - npm has final say on naming disputes. We can go to them with issues.
>
> - Discoverability
>     - npm Ecosystems will be up sometime this year
>     - stopgap: they can give us list of plugins based on ecosystem:cordova
> keyword that we could use as data in our existing plugins site
>     - you can already find all of our plugins on npm via searching
> ecosystem:cordova (https://www.npmjs.com/search?q=ecosystem%3Acordova)
>
> - Documentation
>     - They don't have a way to handle uploading anything other than readme
> to npm
>     - we could build our own packager that could publish doc/en/index.md,
> but not worth it
>     - Potential Solution: Copy doc/en/index.md into readme, also add
> links to other language documentation in readme that points to github
> markdown files
>     - Internationalization is something they want to solve, just no cycles
> for it in the immediate future
>
> - Dependency, Multiple versions of same plugin issue
>     - This one was tricky. They don't have a good solution really
>     - Seems like best case is to use peer dependencies in package.json
> files of plugins. Users will get a warning about missing dependency and
> will have to explicitly install the missing dependency. Make it a userland
> problem.
>     - Ex: user installs cordova-plugin-file-transfer, they will see a
> warning about having to install cordova-plugin-file (maybe a specific
> version)
>     - This would insure plugins are flat and should prevent multiple
> versions of the same plugin to be installed.
>
> - Plugin Post Install Hooks
>     - It was brought up that having a generic post install hook that could
> move native files into cordova projects might be a good solution. I know we
> discussed it briefly and decided it would be to hard to get right. After
> more thought and discussion, I think we should revisit this as a potential
> solution. We wouldn't be dependent on cordova-lib/plugman to install
> plugins anymore. As long as plugins still have plugin.xml (which they will
> for a little while), we could still support the cordova-lib/plugman
> workflow too. Lets discuss this more in its own thread.
>

Yes, lets start a new thread.  Have many questions ;)


>
> Plugin TODO:
> - Rename id to package-name in package.json files and plugin.xml
>

+1


> - move english documentation into readme, add links for other languages
> into readme pointing to github markdown files
>

+1


> - Add peer dependencies to package.json
>

+1, especially for as long as we are still fetching via
plugman/cordova-cli.  Though for the record, the plan for npm 3.0 seems to
be to have a flat hierarchy even for dependencies.  Was this discussed?


> - Major bump plugin versions
>

+1


>
> Tools TODO:
> - NPM fetch as fallback
>

Do we agree to go directly to NPM if we know for sure the plugin name fails
the CPR publishing requirements (aka, is not in reverse domain format)?


> - Mapper module will only warn to use the new name, won't actually
> redirect. We can turn on redirecting when we default to npm or shutdown
> cpr.
>

Fair enough for step 1!


>
> Today I am working on the tools todos.
>
> On Mon, Feb 23, 2015 at 7:55 PM, Michal Mocny <mmocny@chromium.org> wrote:
>
>> Summarizing conclusions so far (not 100% we all agree on this, please do
>> speak up):
>>
>> - PluginId and Npm Package Name should be the same.  We cannot force this
>> for all plugins, but we can set the tone with core plugins.
>> - We will change all plugins to use the cordova-plugin-* name/id.
>> - We will bump MAJOR version to signal this change, and so plugins that
>> depend on core plugins know to update to reflect the id change.
>> - Publish old versions of plugins with the new package name but old plugin
>> ids to npm.
>> - CPR will be hit first, then fallback to npm, for the first N months.
>>   - We could go directly to npm first if the name is known to not match
>> CPR
>> requirements (i.e. cordova-plugin-* is known to not be in CPR by existing
>> plugin id requirements)
>> - Mapper module can help transition users of old ids to new package names,
>> by warning that plugins have moved, and (perhaps?) automatically
>> redirecting.
>>   - If we drop the automatic redirection requirement, we could just update
>> CPR plugins with <info> inform users of the change.
>>
>> I think thats it..
>>
>> Steve, mind updating us on how far along you are, and with what you would
>> like help?
>>
>> -Michal
>>
>> On Mon, Feb 23, 2015 at 10:44 PM, Michal Mocny <mmocny@chromium.org>
>> wrote:
>>
>> > Just thinking out loud..
>> >
>> > I guess it wouldn't actually do that unless you are using actual npm cli
>> > to install plugins.  With the current plan we are still just using
>> > cordova/plugman to fetch using the npm lib, and so can probably resolve
>> > peerDependencies whenever/however we want (like auto-fetching only once
>> the
>> > platform is added).
>> >
>> > If we did move to top-level package.json and installing dependencies via
>> > npm, it may be a little annoying to have that message.
>> >
>> > I guess the reason we are discussing dropping <dependency> anyway was
>> for
>> > the move to using npm cli directly, and since we are still a ways away
>> from
>> > that, I guess we can punt this change for now and keep using a tag?
>> >
>> > -Michal
>> >
>> > On Mon, Feb 23, 2015 at 9:52 PM, Andrew Grieve <agrieve@chromium.org>
>> > wrote:
>> >
>> >> 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 <mmocny@chromium.org>
>> >> 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 <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>
>> >>> >> > > >
>> >>> >> > >
>> >>> >> >
>> >>> >>
>> >>> >
>> >>> >
>> >>>
>> >>
>> >>
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message