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 Tue, 24 Feb 2015 03:55:43 GMT
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