cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Schedule for npm transition
Date Tue, 24 Feb 2015 02:52:50 GMT
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