You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Gorkem Ercan <go...@gmail.com> on 2015/02/11 18:10:46 UTC
Schedule for npm transition
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
For additional commands, e-mail: dev-help@cordova.apache.org
Re: Schedule for npm transition
Posted by Michal Mocny <mm...@chromium.org>.
Leo, the rename isn't required, as a third party author you can publish
your plugin using the plugin id to npm, and no mapping is required.
But for cordova core plugins, we think the plugin id is a bad choice for
package name for aesthetic reasons, and the fixed name mapping solution
provides us with compatability. I think its a good forward looking choice.
-Michal
On Wed, Feb 11, 2015 at 3:50 PM, Michal Mocny <mm...@chromium.org> wrote:
> Leo, restore will still work. The only information stored in the saves
> list is a set of plugin ids (and versions?). Restoring will go through the
> steps Steve outlines above, and either download from CPR or be mapped
> automatically to the npm equivalent. After the deprecation cutoff, plugins
> that aren't in the mapper may fail to restore -- so we could improve the
> rollout plan by starting to warn users adding plugins that still fetch from
> CPR.
>
> -Michal
>
> On Wed, Feb 11, 2015 at 2:58 PM, Treggiari, Leo <le...@intel.com>
> wrote:
>
>> The proposal contains suggestions, alternatives and comments.
>>
>> >
>> https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP-9DpYkcmfs/edit?usp=sharing
>>
>> When will there be a final version that is the official plan?
>>
>> One other question: Soon we will have optional 'save' of plugin metadata
>> in config.xml. When CPR is turned off, there will be saved metadata which
>> is no longer valid - i.e. a restore will fail. This is because the 'name'
>> used to fetch a plugin (cordova-plugin-device) as well as the location will
>> change. Is there anything that can be done to mitigate that? Is the name
>> change really necessary - why can't we stick with the current names?
>>
>> Thanks,
>> Leo
>>
>> -----Original Message-----
>> From: Steven Gill [mailto:stevengill97@gmail.com]
>> Sent: Wednesday, February 11, 2015 11:40 AM
>> To: dev@cordova.apache.org
>> Subject: Re: Schedule for npm transition
>>
>> 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.
>>
>> 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.
>>
>> 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 <mm...@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 <st...@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
>> >
>> > > 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
>> > > > 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
>>
>>
>
Re: Schedule for npm transition
Posted by Andrew Grieve <ag...@chromium.org>.
I see no reason why we shouldn't post old versions. It's easy to do.
On Fri, Feb 13, 2015 at 4:42 PM, Treggiari, Leo <le...@intel.com>
wrote:
> I have another question which I don't remember being discussed.
>
> Will older versions of the core plugins be published in NPM? I ask
> because existing user projects may reference previous versions of plugins
> and may want to be able to continue to fetch them for quite some time.
> This is separate from the 'mapper' functionality. E.g. will a user be able
> to request cordova-plugin-camera@0.3.4? Note that I see that the current
> version is 0.3.5, and I don't actually know how old 0.3.4 is.
>
> These versioned references can come from a number of places including (as
> Andrew pointed out and with one addition from me):
> 1. <dependency> within plugin.xml.
> 2. <plugin> within config.xml (for cordova plugin restore).
> 3. <plugin> within config.xml (or some other source of metadata) for a
> 'cloud' Cordova build system.
>
> Thanks,
> Leo
>
> -----Original Message-----
> From: Shazron [mailto:shazron@gmail.com]
> Sent: Wednesday, February 11, 2015 3:48 PM
> To: dev@cordova.apache.org
> Subject: Re: Schedule for npm transition
>
> I agree with Steve to move forward with this. The package name
> rationale was already discussed during the hangout, and we all agreed.
>
> On Wed, Feb 11, 2015 at 3:43 PM, Steven Gill <st...@gmail.com>
> wrote:
> > Mapper: https://github.com/stevengill/cordova-registry-mapper
> >
> > Mapper would be a dependency of cordova-lib. We would use it during
> cordova
> > plugin add/rm to map old id's to new name.
> >
> > We can look at extending CPR readonly phase but I fear we may have to
> deal
> > with migrating it to a different provider if want to extend its life. I
> am
> > not looking forward to dealing with that.
> >
> > In terms of package-name/package-id, we have been discussing it for
> weeks.
> > I am not a fan of the flip flopping on this issue and it is seriously
> > holding up us moving forward with this. Michal did a great job explaining
> > how the mapper could be integrated to handle the workflows.
> >
> >
> >
> > On Wed, Feb 11, 2015 at 3:20 PM, Gorkem Ercan <go...@gmail.com>
> > wrote:
> >
> >>
> >>
> >> On 11 Feb 2015, at 15:50, Michal Mocny wrote:
> >>
> >> Leo, restore will still work. The only information stored in the saves
> >>> list is a set of plugin ids (and versions?). Restoring will go through
> >>> the
> >>> steps Steve outlines above, and either download from CPR or be mapped
> >>> automatically to the npm equivalent. After the deprecation cutoff,
> >>> plugins
> >>> that aren't in the mapper may fail to restore -- so we could improve
> the
> >>>
> >>
> >> Any ideas what that mapper will look like? part of CLI, online service?
> >>
> >>
> >>
> >> rollout plan by starting to warn users adding plugins that still fetch
> >>> from
> >>> CPR.
> >>>
> >>> -Michal
> >>>
> >>> On Wed, Feb 11, 2015 at 2:58 PM, Treggiari, Leo <
> leo.treggiari@intel.com>
> >>> wrote:
> >>>
> >>> The proposal contains suggestions, alternatives and comments.
> >>>>
> >>>>
> >>>>> https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3
> >>>> OXmP-9DpYkcmfs/edit?usp=sharing
> >>>>
> >>>> When will there be a final version that is the official plan?
> >>>>
> >>>> One other question: Soon we will have optional 'save' of plugin
> metadata
> >>>> in config.xml. When CPR is turned off, there will be saved metadata
> >>>> which
> >>>> is no longer valid - i.e. a restore will fail. This is because the
> >>>> 'name'
> >>>> used to fetch a plugin (cordova-plugin-device) as well as the location
> >>>> will
> >>>> change. Is there anything that can be done to mitigate that? Is the
> >>>> name
> >>>> change really necessary - why can't we stick with the current names?
> >>>>
> >>>> Thanks,
> >>>> Leo
> >>>>
> >>>> -----Original Message-----
> >>>> From: Steven Gill [mailto:stevengill97@gmail.com]
> >>>> Sent: Wednesday, February 11, 2015 11:40 AM
> >>>> To: dev@cordova.apache.org
> >>>> Subject: Re: Schedule for npm transition
> >>>>
> >>>> 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.
> >>>>
> >>>> 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.
> >>>>
> >>>> 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 <mm...@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
> >
> >>>>> 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/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3
> >>>> OXmP-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>
> >>>>>> 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
> >>>>>>> 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
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
RE: Schedule for npm transition
Posted by "Treggiari, Leo" <le...@intel.com>.
I have another question which I don't remember being discussed.
Will older versions of the core plugins be published in NPM? I ask because existing user projects may reference previous versions of plugins and may want to be able to continue to fetch them for quite some time. This is separate from the 'mapper' functionality. E.g. will a user be able to request cordova-plugin-camera@0.3.4? Note that I see that the current version is 0.3.5, and I don't actually know how old 0.3.4 is.
These versioned references can come from a number of places including (as Andrew pointed out and with one addition from me):
1. <dependency> within plugin.xml.
2. <plugin> within config.xml (for cordova plugin restore).
3. <plugin> within config.xml (or some other source of metadata) for a 'cloud' Cordova build system.
Thanks,
Leo
-----Original Message-----
From: Shazron [mailto:shazron@gmail.com]
Sent: Wednesday, February 11, 2015 3:48 PM
To: dev@cordova.apache.org
Subject: Re: Schedule for npm transition
I agree with Steve to move forward with this. The package name
rationale was already discussed during the hangout, and we all agreed.
On Wed, Feb 11, 2015 at 3:43 PM, Steven Gill <st...@gmail.com> wrote:
> Mapper: https://github.com/stevengill/cordova-registry-mapper
>
> Mapper would be a dependency of cordova-lib. We would use it during cordova
> plugin add/rm to map old id's to new name.
>
> We can look at extending CPR readonly phase but I fear we may have to deal
> with migrating it to a different provider if want to extend its life. I am
> not looking forward to dealing with that.
>
> In terms of package-name/package-id, we have been discussing it for weeks.
> I am not a fan of the flip flopping on this issue and it is seriously
> holding up us moving forward with this. Michal did a great job explaining
> how the mapper could be integrated to handle the workflows.
>
>
>
> On Wed, Feb 11, 2015 at 3:20 PM, Gorkem Ercan <go...@gmail.com>
> wrote:
>
>>
>>
>> On 11 Feb 2015, at 15:50, Michal Mocny wrote:
>>
>> Leo, restore will still work. The only information stored in the saves
>>> list is a set of plugin ids (and versions?). Restoring will go through
>>> the
>>> steps Steve outlines above, and either download from CPR or be mapped
>>> automatically to the npm equivalent. After the deprecation cutoff,
>>> plugins
>>> that aren't in the mapper may fail to restore -- so we could improve the
>>>
>>
>> Any ideas what that mapper will look like? part of CLI, online service?
>>
>>
>>
>> rollout plan by starting to warn users adding plugins that still fetch
>>> from
>>> CPR.
>>>
>>> -Michal
>>>
>>> On Wed, Feb 11, 2015 at 2:58 PM, Treggiari, Leo <le...@intel.com>
>>> wrote:
>>>
>>> The proposal contains suggestions, alternatives and comments.
>>>>
>>>>
>>>>> https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3
>>>> OXmP-9DpYkcmfs/edit?usp=sharing
>>>>
>>>> When will there be a final version that is the official plan?
>>>>
>>>> One other question: Soon we will have optional 'save' of plugin metadata
>>>> in config.xml. When CPR is turned off, there will be saved metadata
>>>> which
>>>> is no longer valid - i.e. a restore will fail. This is because the
>>>> 'name'
>>>> used to fetch a plugin (cordova-plugin-device) as well as the location
>>>> will
>>>> change. Is there anything that can be done to mitigate that? Is the
>>>> name
>>>> change really necessary - why can't we stick with the current names?
>>>>
>>>> Thanks,
>>>> Leo
>>>>
>>>> -----Original Message-----
>>>> From: Steven Gill [mailto:stevengill97@gmail.com]
>>>> Sent: Wednesday, February 11, 2015 11:40 AM
>>>> To: dev@cordova.apache.org
>>>> Subject: Re: Schedule for npm transition
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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 <mm...@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 <st...@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/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3
>>>> OXmP-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 <go...@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
>>>>>>> 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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: Schedule for npm transition
Posted by Shazron <sh...@gmail.com>.
I agree with Steve to move forward with this. The package name
rationale was already discussed during the hangout, and we all agreed.
On Wed, Feb 11, 2015 at 3:43 PM, Steven Gill <st...@gmail.com> wrote:
> Mapper: https://github.com/stevengill/cordova-registry-mapper
>
> Mapper would be a dependency of cordova-lib. We would use it during cordova
> plugin add/rm to map old id's to new name.
>
> We can look at extending CPR readonly phase but I fear we may have to deal
> with migrating it to a different provider if want to extend its life. I am
> not looking forward to dealing with that.
>
> In terms of package-name/package-id, we have been discussing it for weeks.
> I am not a fan of the flip flopping on this issue and it is seriously
> holding up us moving forward with this. Michal did a great job explaining
> how the mapper could be integrated to handle the workflows.
>
>
>
> On Wed, Feb 11, 2015 at 3:20 PM, Gorkem Ercan <go...@gmail.com>
> wrote:
>
>>
>>
>> On 11 Feb 2015, at 15:50, Michal Mocny wrote:
>>
>> Leo, restore will still work. The only information stored in the saves
>>> list is a set of plugin ids (and versions?). Restoring will go through
>>> the
>>> steps Steve outlines above, and either download from CPR or be mapped
>>> automatically to the npm equivalent. After the deprecation cutoff,
>>> plugins
>>> that aren't in the mapper may fail to restore -- so we could improve the
>>>
>>
>> Any ideas what that mapper will look like? part of CLI, online service?
>>
>>
>>
>> rollout plan by starting to warn users adding plugins that still fetch
>>> from
>>> CPR.
>>>
>>> -Michal
>>>
>>> On Wed, Feb 11, 2015 at 2:58 PM, Treggiari, Leo <le...@intel.com>
>>> wrote:
>>>
>>> The proposal contains suggestions, alternatives and comments.
>>>>
>>>>
>>>>> https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3
>>>> OXmP-9DpYkcmfs/edit?usp=sharing
>>>>
>>>> When will there be a final version that is the official plan?
>>>>
>>>> One other question: Soon we will have optional 'save' of plugin metadata
>>>> in config.xml. When CPR is turned off, there will be saved metadata
>>>> which
>>>> is no longer valid - i.e. a restore will fail. This is because the
>>>> 'name'
>>>> used to fetch a plugin (cordova-plugin-device) as well as the location
>>>> will
>>>> change. Is there anything that can be done to mitigate that? Is the
>>>> name
>>>> change really necessary - why can't we stick with the current names?
>>>>
>>>> Thanks,
>>>> Leo
>>>>
>>>> -----Original Message-----
>>>> From: Steven Gill [mailto:stevengill97@gmail.com]
>>>> Sent: Wednesday, February 11, 2015 11:40 AM
>>>> To: dev@cordova.apache.org
>>>> Subject: Re: Schedule for npm transition
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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 <mm...@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 <st...@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/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3
>>>> OXmP-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 <go...@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
>>>>>>> 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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: Schedule for npm transition
Posted by Steven Gill <st...@gmail.com>.
Mapper: https://github.com/stevengill/cordova-registry-mapper
Mapper would be a dependency of cordova-lib. We would use it during cordova
plugin add/rm to map old id's to new name.
We can look at extending CPR readonly phase but I fear we may have to deal
with migrating it to a different provider if want to extend its life. I am
not looking forward to dealing with that.
In terms of package-name/package-id, we have been discussing it for weeks.
I am not a fan of the flip flopping on this issue and it is seriously
holding up us moving forward with this. Michal did a great job explaining
how the mapper could be integrated to handle the workflows.
On Wed, Feb 11, 2015 at 3:20 PM, Gorkem Ercan <go...@gmail.com>
wrote:
>
>
> On 11 Feb 2015, at 15:50, Michal Mocny wrote:
>
> Leo, restore will still work. The only information stored in the saves
>> list is a set of plugin ids (and versions?). Restoring will go through
>> the
>> steps Steve outlines above, and either download from CPR or be mapped
>> automatically to the npm equivalent. After the deprecation cutoff,
>> plugins
>> that aren't in the mapper may fail to restore -- so we could improve the
>>
>
> Any ideas what that mapper will look like? part of CLI, online service?
>
>
>
> rollout plan by starting to warn users adding plugins that still fetch
>> from
>> CPR.
>>
>> -Michal
>>
>> On Wed, Feb 11, 2015 at 2:58 PM, Treggiari, Leo <le...@intel.com>
>> wrote:
>>
>> The proposal contains suggestions, alternatives and comments.
>>>
>>>
>>>> https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3
>>> OXmP-9DpYkcmfs/edit?usp=sharing
>>>
>>> When will there be a final version that is the official plan?
>>>
>>> One other question: Soon we will have optional 'save' of plugin metadata
>>> in config.xml. When CPR is turned off, there will be saved metadata
>>> which
>>> is no longer valid - i.e. a restore will fail. This is because the
>>> 'name'
>>> used to fetch a plugin (cordova-plugin-device) as well as the location
>>> will
>>> change. Is there anything that can be done to mitigate that? Is the
>>> name
>>> change really necessary - why can't we stick with the current names?
>>>
>>> Thanks,
>>> Leo
>>>
>>> -----Original Message-----
>>> From: Steven Gill [mailto:stevengill97@gmail.com]
>>> Sent: Wednesday, February 11, 2015 11:40 AM
>>> To: dev@cordova.apache.org
>>> Subject: Re: Schedule for npm transition
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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 <mm...@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 <st...@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/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3
>>> OXmP-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 <go...@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
>>>>>> 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
>
>
Re: Schedule for npm transition
Posted by Gorkem Ercan <go...@gmail.com>.
On 11 Feb 2015, at 15:50, Michal Mocny wrote:
> Leo, restore will still work. The only information stored in the
> saves
> list is a set of plugin ids (and versions?). Restoring will go
> through the
> steps Steve outlines above, and either download from CPR or be mapped
> automatically to the npm equivalent. After the deprecation cutoff,
> plugins
> that aren't in the mapper may fail to restore -- so we could improve
> the
Any ideas what that mapper will look like? part of CLI, online service?
> rollout plan by starting to warn users adding plugins that still fetch
> from
> CPR.
>
> -Michal
>
> On Wed, Feb 11, 2015 at 2:58 PM, Treggiari, Leo
> <le...@intel.com>
> wrote:
>
>> The proposal contains suggestions, alternatives and comments.
>>
>>>
>> https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP-9DpYkcmfs/edit?usp=sharing
>>
>> When will there be a final version that is the official plan?
>>
>> One other question: Soon we will have optional 'save' of plugin
>> metadata
>> in config.xml. When CPR is turned off, there will be saved metadata
>> which
>> is no longer valid - i.e. a restore will fail. This is because the
>> 'name'
>> used to fetch a plugin (cordova-plugin-device) as well as the
>> location will
>> change. Is there anything that can be done to mitigate that? Is
>> the name
>> change really necessary - why can't we stick with the current names?
>>
>> Thanks,
>> Leo
>>
>> -----Original Message-----
>> From: Steven Gill [mailto:stevengill97@gmail.com]
>> Sent: Wednesday, February 11, 2015 11:40 AM
>> To: dev@cordova.apache.org
>> Subject: Re: Schedule for npm transition
>>
>> 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.
>>
>> 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.
>>
>> 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 <mm...@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
>>> <st...@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
>>>> <go...@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
>>>>> 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
Re: Schedule for npm transition
Posted by Michal Mocny <mm...@chromium.org>.
Leo, restore will still work. The only information stored in the saves
list is a set of plugin ids (and versions?). Restoring will go through the
steps Steve outlines above, and either download from CPR or be mapped
automatically to the npm equivalent. After the deprecation cutoff, plugins
that aren't in the mapper may fail to restore -- so we could improve the
rollout plan by starting to warn users adding plugins that still fetch from
CPR.
-Michal
On Wed, Feb 11, 2015 at 2:58 PM, Treggiari, Leo <le...@intel.com>
wrote:
> The proposal contains suggestions, alternatives and comments.
>
> >
> https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP-9DpYkcmfs/edit?usp=sharing
>
> When will there be a final version that is the official plan?
>
> One other question: Soon we will have optional 'save' of plugin metadata
> in config.xml. When CPR is turned off, there will be saved metadata which
> is no longer valid - i.e. a restore will fail. This is because the 'name'
> used to fetch a plugin (cordova-plugin-device) as well as the location will
> change. Is there anything that can be done to mitigate that? Is the name
> change really necessary - why can't we stick with the current names?
>
> Thanks,
> Leo
>
> -----Original Message-----
> From: Steven Gill [mailto:stevengill97@gmail.com]
> Sent: Wednesday, February 11, 2015 11:40 AM
> To: dev@cordova.apache.org
> Subject: Re: Schedule for npm transition
>
> 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.
>
> 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.
>
> 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 <mm...@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 <st...@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 <go...@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
> > > > 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
>
>
RE: Schedule for npm transition
Posted by "Treggiari, Leo" <le...@intel.com>.
The proposal contains suggestions, alternatives and comments.
> https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP-9DpYkcmfs/edit?usp=sharing
When will there be a final version that is the official plan?
One other question: Soon we will have optional 'save' of plugin metadata in config.xml. When CPR is turned off, there will be saved metadata which is no longer valid - i.e. a restore will fail. This is because the 'name' used to fetch a plugin (cordova-plugin-device) as well as the location will change. Is there anything that can be done to mitigate that? Is the name change really necessary - why can't we stick with the current names?
Thanks,
Leo
-----Original Message-----
From: Steven Gill [mailto:stevengill97@gmail.com]
Sent: Wednesday, February 11, 2015 11:40 AM
To: dev@cordova.apache.org
Subject: Re: Schedule for npm transition
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.
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.
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 <mm...@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 <st...@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 <go...@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
> > > 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
Re: Schedule for npm transition
Posted by Michal Mocny <mm...@chromium.org>.
On Wed, Feb 25, 2015 at 3:08 PM, Steven Gill <st...@gmail.com> wrote:
> All versions of released core plugins have been published to npm.
> https://issues.apache.org/jira/browse/CB-8529
> All our core plugins now have a package.json file.
> https://issues.apache.org/jira/browse/CB-8538
>
> A few of us from Adobe met with NPM yesterday. Summary:
>
> - Migration
> - Use 'ecosystem:cordova' as a keyword in plugins for discoverability
> (instead of 'cordovaplugin'). I updated createpackagejson already with this.
> - npm has final say on naming disputes. We can go to them with issues.
>
> - Discoverability
> - npm Ecosystems will be up sometime this year
> - stopgap: they can give us list of plugins based on ecosystem:cordova
> keyword that we could use as data in our existing plugins site
> - you can already find all of our plugins on npm via searching
> ecosystem:cordova (https://www.npmjs.com/search?q=ecosystem%3Acordova)
>
> - Documentation
> - They don't have a way to handle uploading anything other than readme
> to npm
> - we could build our own packager that could publish doc/en/index.md,
> but not worth it
> - Potential Solution: Copy doc/en/index.md into readme, also add
> links to other language documentation in readme that points to github
> markdown files
> - Internationalization is something they want to solve, just no cycles
> for it in the immediate future
>
> - Dependency, Multiple versions of same plugin issue
> - This one was tricky. They don't have a good solution really
> - Seems like best case is to use peer dependencies in package.json
> files of plugins. Users will get a warning about missing dependency and
> will have to explicitly install the missing dependency. Make it a userland
> problem.
> - Ex: user installs cordova-plugin-file-transfer, they will see a
> warning about having to install cordova-plugin-file (maybe a specific
> version)
> - This would insure plugins are flat and should prevent multiple
> versions of the same plugin to be installed.
>
> - Plugin Post Install Hooks
> - It was brought up that having a generic post install hook that could
> move native files into cordova projects might be a good solution. I know we
> discussed it briefly and decided it would be to hard to get right. After
> more thought and discussion, I think we should revisit this as a potential
> solution. We wouldn't be dependent on cordova-lib/plugman to install
> plugins anymore. As long as plugins still have plugin.xml (which they will
> for a little while), we could still support the cordova-lib/plugman
> workflow too. Lets discuss this more in its own thread.
>
Yes, lets start a new thread. Have many questions ;)
>
> Plugin TODO:
> - Rename id to package-name in package.json files and plugin.xml
>
+1
> - move english documentation into readme, add links for other languages
> into readme pointing to github markdown files
>
+1
> - Add peer dependencies to package.json
>
+1, especially for as long as we are still fetching via
plugman/cordova-cli. Though for the record, the plan for npm 3.0 seems to
be to have a flat hierarchy even for dependencies. Was this discussed?
> - Major bump plugin versions
>
+1
>
> Tools TODO:
> - NPM fetch as fallback
>
Do we agree to go directly to NPM if we know for sure the plugin name fails
the CPR publishing requirements (aka, is not in reverse domain format)?
> - Mapper module will only warn to use the new name, won't actually
> redirect. We can turn on redirecting when we default to npm or shutdown
> cpr.
>
Fair enough for step 1!
>
> Today I am working on the tools todos.
>
> On Mon, Feb 23, 2015 at 7:55 PM, Michal Mocny <mm...@chromium.org> wrote:
>
>> Summarizing conclusions so far (not 100% we all agree on this, please do
>> speak up):
>>
>> - PluginId and Npm Package Name should be the same. We cannot force this
>> for all plugins, but we can set the tone with core plugins.
>> - We will change all plugins to use the cordova-plugin-* name/id.
>> - We will bump MAJOR version to signal this change, and so plugins that
>> depend on core plugins know to update to reflect the id change.
>> - Publish old versions of plugins with the new package name but old plugin
>> ids to npm.
>> - CPR will be hit first, then fallback to npm, for the first N months.
>> - We could go directly to npm first if the name is known to not match
>> CPR
>> requirements (i.e. cordova-plugin-* is known to not be in CPR by existing
>> plugin id requirements)
>> - Mapper module can help transition users of old ids to new package names,
>> by warning that plugins have moved, and (perhaps?) automatically
>> redirecting.
>> - If we drop the automatic redirection requirement, we could just update
>> CPR plugins with <info> inform users of the change.
>>
>> I think thats it..
>>
>> Steve, mind updating us on how far along you are, and with what you would
>> like help?
>>
>> -Michal
>>
>> On Mon, Feb 23, 2015 at 10:44 PM, Michal Mocny <mm...@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 <ag...@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 <mm...@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 <mm...@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
>> >>> >> > > > > <ma...@chromium.org>>
>> >>> >> > > > >
>> >>> >> > > > > wrote:
>> >>> >> > > > >
>> >>> >> > > > >
>> >>> >> > > > >
>> >>> >> > > > > > On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny <
>> >>> >> > mmocny@chromium.org
>> >>> >> > > > > <ma...@chromium.org>>
>> >>> >> > > > >
>> >>> >> > > > > > wrote:
>> >>> >> > > > >
>> >>> >> > > > > >
>> >>> >> > > > >
>> >>> >> > > > > > > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve
>> >>> >> > > > >
>> >>> >> > > > > > > <ag...@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
>> >>> >> > > > >
>> >>> >> > > > > > > > <mm...@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<ma...@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<ma...@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
>> >>> >> > > > <cs...@gmail.com>
>> >>> >> > > >
>> >>> >> > >
>> >>> >> >
>> >>> >>
>> >>> >
>> >>> >
>> >>>
>> >>
>> >>
>> >
>>
>
>
Re: Schedule for npm transition
Posted by Steven Gill <st...@gmail.com>.
All versions of released core plugins have been published to npm.
https://issues.apache.org/jira/browse/CB-8529
All our core plugins now have a package.json file.
https://issues.apache.org/jira/browse/CB-8538
A few of us from Adobe met with NPM yesterday. Summary:
- Migration
- Use 'ecosystem:cordova' as a keyword in plugins for discoverability
(instead of 'cordovaplugin'). I updated createpackagejson already with this.
- npm has final say on naming disputes. We can go to them with issues.
- Discoverability
- npm Ecosystems will be up sometime this year
- stopgap: they can give us list of plugins based on ecosystem:cordova
keyword that we could use as data in our existing plugins site
- you can already find all of our plugins on npm via searching
ecosystem:cordova (https://www.npmjs.com/search?q=ecosystem%3Acordova)
- Documentation
- They don't have a way to handle uploading anything other than readme
to npm
- we could build our own packager that could publish doc/en/index.md,
but not worth it
- Potential Solution: Copy doc/en/index.md into readme, also add links
to other language documentation in readme that points to github markdown
files
- Internationalization is something they want to solve, just no cycles
for it in the immediate future
- Dependency, Multiple versions of same plugin issue
- This one was tricky. They don't have a good solution really
- Seems like best case is to use peer dependencies in package.json
files of plugins. Users will get a warning about missing dependency and
will have to explicitly install the missing dependency. Make it a userland
problem.
- Ex: user installs cordova-plugin-file-transfer, they will see a
warning about having to install cordova-plugin-file (maybe a specific
version)
- This would insure plugins are flat and should prevent multiple
versions of the same plugin to be installed.
- Plugin Post Install Hooks
- It was brought up that having a generic post install hook that could
move native files into cordova projects might be a good solution. I know we
discussed it briefly and decided it would be to hard to get right. After
more thought and discussion, I think we should revisit this as a potential
solution. We wouldn't be dependent on cordova-lib/plugman to install
plugins anymore. As long as plugins still have plugin.xml (which they will
for a little while), we could still support the cordova-lib/plugman
workflow too. Lets discuss this more in its own thread.
Plugin TODO:
- Rename id to package-name in package.json files and plugin.xml
- move english documentation into readme, add links for other languages
into readme pointing to github markdown files
- Add peer dependencies to package.json
- Major bump plugin versions
Tools TODO:
- NPM fetch as fallback
- Mapper module will only warn to use the new name, won't actually
redirect. We can turn on redirecting when we default to npm or shutdown
cpr.
Today I am working on the tools todos.
On Mon, Feb 23, 2015 at 7:55 PM, Michal Mocny <mm...@chromium.org> wrote:
> Summarizing conclusions so far (not 100% we all agree on this, please do
> speak up):
>
> - PluginId and Npm Package Name should be the same. We cannot force this
> for all plugins, but we can set the tone with core plugins.
> - We will change all plugins to use the cordova-plugin-* name/id.
> - We will bump MAJOR version to signal this change, and so plugins that
> depend on core plugins know to update to reflect the id change.
> - Publish old versions of plugins with the new package name but old plugin
> ids to npm.
> - CPR will be hit first, then fallback to npm, for the first N months.
> - We could go directly to npm first if the name is known to not match CPR
> requirements (i.e. cordova-plugin-* is known to not be in CPR by existing
> plugin id requirements)
> - Mapper module can help transition users of old ids to new package names,
> by warning that plugins have moved, and (perhaps?) automatically
> redirecting.
> - If we drop the automatic redirection requirement, we could just update
> CPR plugins with <info> inform users of the change.
>
> I think thats it..
>
> Steve, mind updating us on how far along you are, and with what you would
> like help?
>
> -Michal
>
> On Mon, Feb 23, 2015 at 10:44 PM, Michal Mocny <mm...@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 <ag...@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 <mm...@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 <mm...@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 <mm...@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
> >>> >> > > > > <ma...@chromium.org>>
> >>> >> > > > >
> >>> >> > > > > wrote:
> >>> >> > > > >
> >>> >> > > > >
> >>> >> > > > >
> >>> >> > > > > > On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny <
> >>> >> > mmocny@chromium.org
> >>> >> > > > > <ma...@chromium.org>>
> >>> >> > > > >
> >>> >> > > > > > wrote:
> >>> >> > > > >
> >>> >> > > > > >
> >>> >> > > > >
> >>> >> > > > > > > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve
> >>> >> > > > >
> >>> >> > > > > > > <ag...@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
> >>> >> > > > >
> >>> >> > > > > > > > <mm...@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<ma...@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<ma...@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<ma...@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
> >>> >> > > > <cs...@gmail.com>
> >>> >> > > >
> >>> >> > >
> >>> >> >
> >>> >>
> >>> >
> >>> >
> >>>
> >>
> >>
> >
>
Re: Schedule for npm transition
Posted by Michal Mocny <mm...@chromium.org>.
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 <mm...@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 <ag...@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 <mm...@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 <mm...@chromium.org>
>>> wrote:
>>>
>>> >
>>> >
>>> > On Mon, Feb 23, 2015 at 3:36 PM, Andrew Grieve <ag...@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 <mm...@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
>>> >> > > > > <ma...@chromium.org>>
>>> >> > > > >
>>> >> > > > > wrote:
>>> >> > > > >
>>> >> > > > >
>>> >> > > > >
>>> >> > > > > > On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny <
>>> >> > mmocny@chromium.org
>>> >> > > > > <ma...@chromium.org>>
>>> >> > > > >
>>> >> > > > > > wrote:
>>> >> > > > >
>>> >> > > > > >
>>> >> > > > >
>>> >> > > > > > > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve
>>> >> > > > >
>>> >> > > > > > > <ag...@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
>>> >> > > > >
>>> >> > > > > > > > <mm...@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<ma...@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<ma...@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<ma...@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
>>> >> > > > <cs...@gmail.com>
>>> >> > > >
>>> >> > >
>>> >> >
>>> >>
>>> >
>>> >
>>>
>>
>>
>
Re: Schedule for npm transition
Posted by Michal Mocny <mm...@chromium.org>.
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 <ag...@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 <mm...@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 <mm...@chromium.org>
>> wrote:
>>
>> >
>> >
>> > On Mon, Feb 23, 2015 at 3:36 PM, Andrew Grieve <ag...@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 <mm...@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
>> >> > > > > <ma...@chromium.org>>
>> >> > > > >
>> >> > > > > wrote:
>> >> > > > >
>> >> > > > >
>> >> > > > >
>> >> > > > > > On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny <
>> >> > mmocny@chromium.org
>> >> > > > > <ma...@chromium.org>>
>> >> > > > >
>> >> > > > > > wrote:
>> >> > > > >
>> >> > > > > >
>> >> > > > >
>> >> > > > > > > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve
>> >> > > > >
>> >> > > > > > > <ag...@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
>> >> > > > >
>> >> > > > > > > > <mm...@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<ma...@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<ma...@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<ma...@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
>> >> > > > <cs...@gmail.com>
>> >> > > >
>> >> > >
>> >> >
>> >>
>> >
>> >
>>
>
>
Re: Schedule for npm transition
Posted by Andrew Grieve <ag...@chromium.org>.
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 <mm...@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 <mm...@chromium.org> wrote:
>
> >
> >
> > On Mon, Feb 23, 2015 at 3:36 PM, Andrew Grieve <ag...@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 <mm...@chromium.org>
> >> wrote:
> >>
> >> > On Mon, Feb 23, 2015 at 2:22 PM, Steven Gill <st...@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
> >> > > > > <ma...@chromium.org>>
> >> > > > >
> >> > > > > wrote:
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > > On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny <
> >> > mmocny@chromium.org
> >> > > > > <ma...@chromium.org>>
> >> > > > >
> >> > > > > > wrote:
> >> > > > >
> >> > > > > >
> >> > > > >
> >> > > > > > > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve
> >> > > > >
> >> > > > > > > <ag...@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
> >> > > > >
> >> > > > > > > > <mm...@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<ma...@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<ma...@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<ma...@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
> >> > > > <cs...@gmail.com>
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: Schedule for npm transition
Posted by Michal Mocny <mm...@chromium.org>.
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 <mm...@chromium.org> wrote:
>
>
> On Mon, Feb 23, 2015 at 3:36 PM, Andrew Grieve <ag...@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 <mm...@chromium.org>
>> wrote:
>>
>> > On Mon, Feb 23, 2015 at 2:22 PM, Steven Gill <st...@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 <cl...@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
>> > > > > <ma...@chromium.org>>
>> > > > >
>> > > > > wrote:
>> > > > >
>> > > > >
>> > > > >
>> > > > > > On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny <
>> > mmocny@chromium.org
>> > > > > <ma...@chromium.org>>
>> > > > >
>> > > > > > wrote:
>> > > > >
>> > > > > >
>> > > > >
>> > > > > > > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve
>> > > > >
>> > > > > > > <ag...@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
>> > > > >
>> > > > > > > > <mm...@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<ma...@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<ma...@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<ma...@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<ma...@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<ma...@cordova.apache.org>
>> > > > >
>> > > > > > > > > > > > > >
>> > > > >
>> > > > > > > > > > > > > >
>> > > > >
>> > > > > > > > > > > > >
>> > > > >
>> > > > > > > > > > > >
>> > > > >
>> > > > > > > > > > >
>> > > > >
>> > > > > > > > > >
>> > > > >
>> > > > > > > > >
>> > > > >
>> > > > > > > >
>> > > > >
>> > > > > > >
>> > > > >
>> > > > > >
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Carlos Santana
>> > > > <cs...@gmail.com>
>> > > >
>> > >
>> >
>>
>
>
Re: Schedule for npm transition
Posted by Michal Mocny <mm...@chromium.org>.
On Mon, Feb 23, 2015 at 3:36 PM, Andrew Grieve <ag...@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 <mm...@chromium.org> wrote:
>
> > On Mon, Feb 23, 2015 at 2:22 PM, Steven Gill <st...@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 <cs...@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 <cl...@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
> > > > > <ma...@chromium.org>>
> > > > >
> > > > > wrote:
> > > > >
> > > > >
> > > > >
> > > > > > On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny <
> > mmocny@chromium.org
> > > > > <ma...@chromium.org>>
> > > > >
> > > > > > wrote:
> > > > >
> > > > > >
> > > > >
> > > > > > > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve
> > > > >
> > > > > > > <ag...@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
> > > > >
> > > > > > > > <mm...@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<ma...@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<ma...@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<ma...@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<ma...@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<ma...@cordova.apache.org>
> > > > >
> > > > > > > > > > > > > >
> > > > >
> > > > > > > > > > > > > >
> > > > >
> > > > > > > > > > > > >
> > > > >
> > > > > > > > > > > >
> > > > >
> > > > > > > > > > >
> > > > >
> > > > > > > > > >
> > > > >
> > > > > > > > >
> > > > >
> > > > > > > >
> > > > >
> > > > > > >
> > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Carlos Santana
> > > > <cs...@gmail.com>
> > > >
> > >
> >
>
Re: Schedule for npm transition
Posted by Andrew Grieve <ag...@chromium.org>.
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.
On Mon, Feb 23, 2015 at 2:42 PM, Michal Mocny <mm...@chromium.org> wrote:
> On Mon, Feb 23, 2015 at 2:22 PM, Steven Gill <st...@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 <cs...@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 <cl...@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
> > > > <ma...@chromium.org>>
> > > >
> > > > wrote:
> > > >
> > > >
> > > >
> > > > > On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny <
> mmocny@chromium.org
> > > > <ma...@chromium.org>>
> > > >
> > > > > wrote:
> > > >
> > > > >
> > > >
> > > > > > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve
> > > >
> > > > > > <ag...@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
> > > >
> > > > > > > <mm...@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<ma...@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<ma...@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<ma...@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<ma...@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<ma...@cordova.apache.org>
> > > >
> > > > > > > > > > > > >
> > > >
> > > > > > > > > > > > >
> > > >
> > > > > > > > > > > >
> > > >
> > > > > > > > > > >
> > > >
> > > > > > > > > >
> > > >
> > > > > > > > >
> > > >
> > > > > > > >
> > > >
> > > > > > >
> > > >
> > > > > >
> > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Carlos Santana
> > > <cs...@gmail.com>
> > >
> >
>
Re: Schedule for npm transition
Posted by Michal Mocny <mm...@chromium.org>.
On Mon, Feb 23, 2015 at 2:22 PM, Steven Gill <st...@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 <cs...@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 <cl...@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
> > > <ma...@chromium.org>>
> > >
> > > wrote:
> > >
> > >
> > >
> > > > On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny <mmocny@chromium.org
> > > <ma...@chromium.org>>
> > >
> > > > wrote:
> > >
> > > >
> > >
> > > > > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve
> > >
> > > > > <ag...@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
> > >
> > > > > > <mm...@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<ma...@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<ma...@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<ma...@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<ma...@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<ma...@cordova.apache.org>
> > >
> > > > > > > > > > > >
> > >
> > > > > > > > > > > >
> > >
> > > > > > > > > > >
> > >
> > > > > > > > > >
> > >
> > > > > > > > >
> > >
> > > > > > > >
> > >
> > > > > > >
> > >
> > > > > >
> > >
> > > > >
> > >
> > > >
> > >
> >
> >
> >
> > --
> > Carlos Santana
> > <cs...@gmail.com>
> >
>
Re: Schedule for npm transition
Posted by Steven Gill <st...@gmail.com>.
+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?
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.
On Thu, Feb 19, 2015 at 6:50 AM, Carlos Santana <cs...@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 <cl...@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
> > <ma...@chromium.org>>
> >
> > wrote:
> >
> >
> >
> > > On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny <mmocny@chromium.org
> > <ma...@chromium.org>>
> >
> > > wrote:
> >
> > >
> >
> > > > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve
> >
> > > > <ag...@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
> >
> > > > > <mm...@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<ma...@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<ma...@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<ma...@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<ma...@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<ma...@cordova.apache.org>
> >
> > > > > > > > > > >
> >
> > > > > > > > > > >
> >
> > > > > > > > > >
> >
> > > > > > > > >
> >
> > > > > > > >
> >
> > > > > > >
> >
> > > > > >
> >
> > > > >
> >
> > > >
> >
> > >
> >
>
>
>
> --
> Carlos Santana
> <cs...@gmail.com>
>
Re: Schedule for npm transition
Posted by Carlos Santana <cs...@gmail.com>.
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 <cl...@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
> <ma...@chromium.org>>
>
> wrote:
>
>
>
> > On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny <mmocny@chromium.org
> <ma...@chromium.org>>
>
> > wrote:
>
> >
>
> > > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve
>
> > > <ag...@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
>
> > > > <mm...@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<ma...@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<ma...@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<ma...@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<ma...@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<ma...@cordova.apache.org>
>
> > > > > > > > > >
>
> > > > > > > > > >
>
> > > > > > > > >
>
> > > > > > > >
>
> > > > > > >
>
> > > > > >
>
> > > > >
>
> > > >
>
> > >
>
> >
>
--
Carlos Santana
<cs...@gmail.com>
RE: Schedule for npm transition
Posted by Chuck Lantz <cl...@microsoft.com>.
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 <ag...@chromium.org>>
wrote:
> On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny <mm...@chromium.org>>
> wrote:
>
> > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve
> > <ag...@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
> > > <mm...@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<ma...@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<ma...@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<ma...@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<ma...@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<ma...@cordova.apache.org>
> > > > > > > > > For additional commands, e-mail:
> dev-help@cordova.apache.org<ma...@cordova.apache.org>
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Schedule for npm transition
Posted by Michal Mocny <mm...@chromium.org>.
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 <ag...@chromium.org>
wrote:
> On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny <mm...@chromium.org>
> wrote:
>
> > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve <ag...@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 <mm...@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
> > >
> > > > > 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>
> > > > > > 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
> > > > >
> > > > > > > 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>
> > > > > > > > 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
> > > > > > > > > For additional commands, e-mail:
> dev-help@cordova.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Schedule for npm transition
Posted by Andrew Grieve <ag...@chromium.org>.
On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny <mm...@chromium.org> wrote:
> On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve <ag...@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 <mm...@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 <ag...@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
> >
> > > > 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>
> > > > > 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
> > > >
> > > > > > 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>
> > > > > > > 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
> > > > > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Schedule for npm transition
Posted by Michal Mocny <mm...@chromium.org>.
On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve <ag...@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 <mm...@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.
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.
> - 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 <ag...@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 <st...@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 <mm...@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
> > >
> > > > > 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>
> > > > > > 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
> > > > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Schedule for npm transition
Posted by Andrew Grieve <ag...@chromium.org>.
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 <mm...@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?
Okay, so we don't change the plugin ID, just the package name.
- When people use <dependency>, they should still use plugin ID
- If they "cordova plugin add", we'll allow them to specify NPM package
name *or* plugin ID.
- 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".
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:
- 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 <ag...@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 <st...@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 <mm...@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
> >
> > > > 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>
> > > > > 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
> > > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Schedule for npm transition
Posted by Michal Mocny <mm...@chromium.org>.
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.
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 <ag...@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 <st...@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 <mm...@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 <st...@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>
> > > > 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
> > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Schedule for npm transition
Posted by Andrew Grieve <ag...@chromium.org>.
Going to try and summarize my concerns with the proposal here:
On Wed, Feb 11, 2015 at 2:39 PM, Steven Gill <st...@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 <mm...@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 <st...@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 <go...@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
> > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > >
> > > >
> > >
> >
>
Re: Schedule for npm transition
Posted by Raymond Camden <ra...@gmail.com>.
Query, you say, "if we use the mapper module" - is there a chance that
may not happen, and in 3+ months, folks who do "cordova plugin add
org.apache.cordova.something" will get an error?
Sorry if that's a dumb question, not 100% sure what the "mapper
module" entails.
On Wed, Feb 11, 2015 at 1:39 PM, Steven Gill <st...@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.
>
> 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.
>
> 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 <mm...@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 <st...@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 <go...@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
>> > > For additional commands, e-mail: dev-help@cordova.apache.org
>> > >
>> > >
>> >
>>
--
===========================================================================
Raymond Camden, Developer Advocate for MobileFirst at IBM
Email : raymondcamden@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: Schedule for npm transition
Posted by Steven Gill <st...@gmail.com>.
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.
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.
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 <mm...@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 <st...@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 <go...@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
> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > >
> > >
> >
>
Re: Schedule for npm transition
Posted by Michal Mocny <mm...@chromium.org>.
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 <st...@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 <go...@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
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
>
Re: Schedule for npm transition
Posted by Gorkem Ercan <go...@gmail.com>.
On 11 Feb 2015, at 13:09, Steven Gill 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
>
I was hoping for a longer read-only period, 6 months would be grand.
Unfortunately getting users to switch versions takes time.
> 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 <go...@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
>> 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
Re: Schedule for npm transition
Posted by Steven Gill <st...@gmail.com>.
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 <go...@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
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>