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 Mon, 23 Feb 2015 21:10:04 GMT
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