Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of leo.treggiari@intel.com
 designates 134.134.136.65 as permitted sender)
From: "Treggiari, Leo" <leo.treggiari@intel.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Subject: RE: Plugins to NPM (Phase 1)
Thread-Topic: Plugins to NPM (Phase 1)
Thread-Index: AQHQZmsUryZAEDQ/Ek+rSq7Pmi3cGp0t9wgA//+isqCAABOiwIACSF0AgADkEqA=
Date: Fri, 27 Mar 2015 21:38:00 +0000
Message-ID: 
 <85A3E123BABF314D9D3656D0B4181256448E7A52@FMSMSX103.amr.corp.intel.com>
References: <D137226C.3A104%tony.homer@intel.com>
 <CAMSbhBiuFxJuybXtp6i3ejQThY5OHmbSNe3crN7Y2fWDdAP70A@mail.gmail.com>
 <85A3E123BABF314D9D3656D0B4181256448E629A@FMSMSX103.amr.corp.intel.com>
 <FFD143336FEF2D41AFA4D9CE7E119BA1595390E1@FMSMSX112.amr.corp.intel.com>
 <CAMSbhBjJ7JUZF+sPrjwSMBZCENKtuJPspMnazdyGfLO+CiNCFw@mail.gmail.com>
In-Reply-To: 
 <CAMSbhBjJ7JUZF+sPrjwSMBZCENKtuJPspMnazdyGfLO+CiNCFw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi Steve,

My final questions (until my next final question...  ;-) )

Until the CPR becomes read-only, will the Cordova project plugin releases u=
pdate both CPR and npm or only npm?  I guess they would be the same except =
for the id?  Or has CPR already seen its final update for Cordova project p=
lugins?

In your reply you mentioned:

> Right now, our mapping just spits out a message to use the new name for
> users. It doesn't actually convert the id to the new name, though we will
> probably start doing the conversion automatically at some point.

I had been assuming for the initial support that if the mapper found a matc=
h, it would go to npm - either first and dropback to CPR or CPR then npm. =
=20

Here's why I ask.  In the Intel XDK we want to support both CLI 4.x and CLI=
 5.x (in the same IDE) until CPR is retired.  That presents a few challenge=
s of course, but wrt to the name change, I would like to be able to use the=
 old names both with CLI 4.x and CLI 5.x until we have a release that no lo=
nger supports CLI 4.x.  For example, the current version of the camera plug=
in is 0.3.5.  With the initial npm release there will be a cordova-plugin-c=
amera version 1.0?  If I ask the CLI 5.x for org.apache.cordova.camera@1.0,=
 will that work?

Thanks,
Leo

-----Original Message-----
From: Steven Gill [mailto:stevengill97@gmail.com]=20
Sent: Thursday, March 26, 2015 5:40 PM
To: dev@cordova.apache.org
Subject: Re: Plugins to NPM (Phase 1)

On Wed, Mar 25, 2015 at 2:36 PM, Horn, Julian C <julian.c.horn@intel.com>
wrote:

> I'd like to add some more questions to what Leo asked.
>
> Can anyone explain how the hundreds of plugins that are published in git
> repos are supposed to transition to CLI 5 (and beyond)?  It seems like th=
e
> answer is that they don't change anything.  What if they want to (or
> already do) publish via the registry?  It seems like you can win if you
> keep the id unchanged and add yourself to the mapping table.  But if that=
's
> true, then why are we renaming the core plugins?
>
If you don't change the id, you don't need to be added to the mapping
table. It will just work once we start checking npm first if it is
published as the same id on npm. We decided to rename our core plugins due
to improved readability and fitting in better with the npm ecosystem.

>
> I don't think repo-resident plugins need to update any <dependency> tags
> that refer to core plugins.  That is, you can continue to ask for
> "org.apache.cordova.file".  If you use CLI 5, then the rename logic will
> get you the corresponding plugin from npm.  Or is there some reason why y=
ou
> will eventually have to change your <dependency> tags to use the new
> names.  Of course you better not change a <dependency> tag in your
> repo-resident plugin before October 1, because that will break projects
> that use your plugin but aren't yet using CLI 5.
>

Right now, our mapping just spits out a message to use the new name for
users. It doesn't actually convert the id to the new name, though we will
probably start doing the conversion automatically at some point.

The <dependency> tag is an interesting usecase. Not sure what the best
solution is. For core plugins, we are doing a major version jump and we are
probably going to have a requirement that they require a newer version of
the CLI to work. (using the engine tag). Third party developers could do
something similar. All of this would be a part of the effort to get
developers to update their tools.


> I haven't been able to come up with any strategy for changing the id of a
> repo-resident plugin without great pain.  It's basically equivalent to
> discontinuing your plugin and creating a new one in its place.  So it see=
ms
> to me that if I have any users I would probably want to stick with my
> existing id and repo URL, even if it meant that I couldn't publish my
> plugin in npm format.  Is that a viable strategy, or is there a long term
> plan that EVERY plugin must eventually publish via npm?
>

We will still support installing via git or locally. So npm won't be a
requirement. To clarify, org.your.project.id is valid for npm. You are
welcomed to use the existing id as package-name when publishing to npm.

>
> One final question.  Suppose I have a CLI 4.x project and I want to
> transition to CLI 5.  Do I have to start over at "cordova create project"=
?
>

Depends on what changes land in 5. But currently, it is the same as
updating has been since CLI 3.x.
* Update cordova-cli via npm install -g cordova-cli@5.0.0.
* Update your project platforms if you desire. cordova platform rm android;
cordova platform add android@newVERSION. As far as I know, we don't have
any changes coming into the CLI that prevent older platform versions from
working. Hopefully we can keep this going.

Great questions. Appreciate it.

>
>     Julian
>
> -----Original Message-----
> From: Treggiari, Leo [mailto:leo.treggiari@intel.com]
> Sent: Wednesday, March 25, 2015 3:53 PM
> To: dev@cordova.apache.org
> Subject: RE: Plugins to NPM (Phase 1)
>
> Thanks for the information Steve.  That helps with our planning.  I have =
a
> couple of follow-ups.
>
> > We don't necessarily have to do a major bump for the CLI. We could
> > easily save the major jump until we switch npm fetching as default
> > (approx July 1)
>
> Re: the major bump.  This seems like a "delayed" breaking change.  That
> is, when CPR is removed, all prior CLI releases will be "crippled" to a
> significant degree since no <pluginid> reference will be able to be
> resolved.
>
> Re: ~July 1:  Would you verify my understanding?  For a <pluginid>
> reference which is not in the mapping table, from ~Apr to ~July 1, CPR wi=
ll
> be tried first and if that fails then npm.  From ~July 1 to ~Oct 1, npm
> will be tried first and if that fails then the CPR.  After ~Oct 1, only n=
pm.
>
> Thanks,
> Leo
>
> -----Original Message-----
> From: Steven Gill [mailto:stevengill97@gmail.com]
> Sent: Wednesday, March 25, 2015 11:13 AM
> To: dev@cordova.apache.org
> Subject: Re: Plugins to NPM (Phase 1)
>
> Thanks for answering tony. More comments below.
>
> On Tue, Mar 24, 2015 at 12:45 PM, Homer, Tony <tony.homer@intel.com>
> wrote:
>
> > I=B9ll try to answer some of Leo=B9s questions, but it would be great i=
f
> > someone else (Steve?) could comment.
> >
> > First, though, I=B9ll ask a question of my own.
> > Is there a doc or JIRA task for tracking all of the activity related
> > to moving plugins to NPM?
> > There was the Google Doc that was created last hangout for tracking
> > the proposal, but it doesn=B9t list JIRAs and hasn=B9t been updated sin=
ce
> > January.
> > I found CB-8529, CB-8538 and CB-8551 but they are not linked to a
> > master task JIRA.
> > This is not a jab at Steve at all, I=B9m just wondering if there is or
> > should be a reference for this set of tasks (other than staying caught
> > up with reading the list)?
> >
>
> Good point. I have created a master issue at
> https://issues.apache.org/jira/browse/CB-8743
>
>
> > On to Leo=B9s questions-
> >
> > Will the release be named Cordova 5.0?
> > Unknown at this time?  It seems like this will require a co-ordinated
> > release of CLI, Tools and Plugins, with major version bumps for all.
> >
>
> We haven't discussed this yet. We don't necessarily have to do a major bu=
mp
> for the CLI. We could easily save the major jump until we switch npm
> fetching as default (approx July 1)
>
> >
> > Will it trigger a major revision bump?
> > Yes.
> >
>
> For plugins, yes. All of the core plugins will be getting a major version
> bump shortly.
>
> >
> > What is the current estimate for the release?
> >
> > I would say =B3when it=B9s done=B2 but it would be great to get a more =
specific
> > answer.
> > I=B9m not sure if that=B9s possible?
> >
>
> Aiming for April 1st.
>
> >
> > If release of Phase 1 occurs on April 1 does this mean that the CPR
> > becomes read-only on July 1 and is
> > deleted on Oct 1?
>
> I think the real driver was that there is an external hosting issue with
> > CPR after Oct. 1.
> > The 3 month period was adopted so provide a transition window, but ther=
e
> > is a hard stop on or around Oct. 1.
> > Steve had mentioned this somewhere but I can=B9t find it now.
> >
>
> - CPR becomes read-only July 1st (if we release April 1st)
> - Tools fetch from NPM by default on July 1st (currently checks CPR first=
,
> npm as fallback)
> - We will try to keep CPR open as read-only for as long as possible.
> Nodejitsu people told us they could give us the 6 months but we will see =
if
> we can stretch it. A day will come when we will have to shut down CPR
> though.
>
> >
> > -  On Oct 1, all previous releases of Cordova CLI (< 5.0) will
> immediately
> > be "broken"?
>
>
> > Yes, that is my understanding, although in reading back over the
> > discussion I don=B9t see where it is explicitly addressed.
> > I was assuming that this is intended in part as a forcing function.
> >
>
> Yes. We could look into setting up some redirect service to keep old
> versions working. But for now, we are saying users will have to upgrade.
>
> >
> > Tony
> >
> >
> > On 3/20/15, 11:05 AM, "Treggiari, Leo" <leo.treggiari@intel.com> wrote:
> >
> > >I have a few questions about Phase 1 (and beyond) as I plan how to
> > >migrate the Intel XDK and existing user projects through this change.
> > >
> > >-  Will the release be named Cordova 5.0?  This seems worthy of a majo=
r
> > >bump for the CLI in addition to the plugins.
> > >
> > >-  What is the current estimate for the release?  I assume soon.
> > >
> > >-  For the purpose of my questions, I'll assume the release occurs on
> > >April 1.  This means that the CPR becomes read-only on July 1 and is
> > >deleted on Oct 1?
> > >
> > >-  On Oct 1, all previous releases of Cordova CLI (< 5.0) will
> > >immediately be "broken"?  That is, they cannot add new plugins, they
> > >cannot "restore" plugins, etc.  "Local" and "git repo" plugins continu=
e
> > >to work, but my assumption is that the vast majority of plugins come
> from
> > >CPR (soon to be npm).
> > >
> > >Thanks,
> > >Leo
> > >
> > >-----Original Message-----
> > >From: Steven Gill [mailto:stevengill97@gmail.com]
> > >Sent: Monday, March 09, 2015 5:20 PM
> > >To: dev@cordova.apache.org
> > >Cc: sosah.victor@gmail.com
> > >Subject: Update: Plugins to NPM (Phase 1)
> > >
> > >Our master branch has plugin fetching from npm set as the fallback now=
.
> It
> > >will go directly to npm if the plugin-id entered isn't reverse domain
> name
> > >style. Cordova-lib also warns users to use the package-name instead of
> > >plugin-id when adding plugins that we have renamed and are in
> > >https://github.com/stevengill/cordova-registry-mapper
> > >
> > >Plugins TODO:
> > >
> > >- README: Move doc/en/index.md into README.md. Delete doc/en/index.md.
> > Add
> > >links in README.md that point to github page of translated docs for
> > >plugin.
> > >(ex.
> > >
> >
> https://github.com/apache/cordova-plugin-device/blob/master/doc/es/index.=
m
> > >d).
> > >I'd love to hear from someone (Victor?) working on docs translations
> about
> > >how this change will impact them.
> > >
> > >- Rename plugin-ids to new plugin names in plugin.xml. Anything we
> should
> > >be aware of before we do this? (Ex. rename org.apache.cordova.device t=
o
> > >cordova-plugin-device in plugin.xml)
> > >
> > >- Add peer dependencies to plugins that depend on other plugins (file,
> > >media-capture, etc)
> > >
> > >- Paramedic support for every plugin
> > >
> > >- Major version bump for all core plugins
> > >
> > >- Update plugins release process to use package.json version as main
> > >version and have it update plugin.xml's version. Will do this when we =
do
> > >next release
> > >
> > >Migration TODO:
> > >
> > >- Create blog post talking about migration to npm for community
> > >
> > >- include how we are renaming, suggest they do so if they want to. Wil=
l
> > >suggest they follow the pattern cordova-plugin-*
> > >
> > >- mention https://github.com/stevengill/cordova-registry-mapper for
> > >warning
> > >purposes
> > >- include potential lifespan of CPR (publishing and read only)
> > >- Discuss plugman createpackage.json command
> > >- Discuss keyword: 'ecosystem:cordova'
> > >
> > >
> > >Thoughts? Missing anything?
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
> -Steve
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org