Re: Schedule for npm transition
gt; > >> >>> >> > >> >>> >> > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > On Thu, Feb 19, 2015 at 6:50 AM, Carlos Santana < >> >>> csantan...@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 < >> >>> cla...@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.) >> >>> >> > > &
Re: Schedule for npm transition
. 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 < > >>> csantan...@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. > &
Re: Schedule for npm transition
> 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 < >>> cla...@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 >>>
Re: Schedule for npm transition
t >> >> > 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 < >> csantan...@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 < >> cla...@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 >> >
Re: Schedule for npm transition
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 < > csantan...@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 < > cla...@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 > >>
Re: Schedule for npm transition
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 >> > > 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: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of >> > Michal >> > > > > Mocny >> > > > > Sent: Tuesday, February 17, 2015 9:32 AM >> > > > > To: dev >> > > > > Subject: Re: Schedule for npm transition >> >
Re: Schedule for npm transition
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: mmo...@google.com [mailto:mmo...@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 < > > agri...@chromium.org > > > > > <mailto:agri...@chromium.org>> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny < > > mmo...@chromium.org > > > > > <mailto:mmo...@chromium.org>> > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > >
Re: Schedule for npm transition
ess 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: mmo...@google.com [mailto:mmo...@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 < > agri...@chromium.org > > > > <mailto:agri...@chromium.org>> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny < > mmo...@chromium.org > > > > <mailto:mmo...@chromium.org>> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve > > > > > > > > > > mailto:agri...@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 > > > > > > > > > > > mailto:mmo...@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, > > > > > > > >
Re: Schedule for npm transition
> > 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: mmo...@google.com [mailto:mmo...@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 > > <mailto:agri...@chromium.org>>
> > >
> > > wrote:
> > >
> > >
> > >
> > > > On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny > > <mailto:mmo...@chromium.org>>
> > >
> > > > wrote:
> > >
> > > >
> > >
> > > > > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve
> > >
> > > > > mailto:agri...@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
> > >
> > > > > > mailto:mmo...@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")).
> > >
> > > > > >
> > >
> > >
Re: Schedule for npm transition
+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 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 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: mmo...@google.com [mailto:mmo...@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 > <mailto:agri...@chromium.org>> > > > > wrote: > > > > > > > > > On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny > <mailto:mmo...@chromium.org>> > > > > > wr
Re: Schedule for npm transition
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 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: mmo...@google.com [mailto:mmo...@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 <mailto:agri...@chromium.org>> > > wrote: > > > > > On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny <mailto:mmo...@chromium.org>> > > > wrote: > > > > > > > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve > > > > mailto:agri...@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 > > > > > mailto:mmo...@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 mapp
RE: Schedule for npm transition
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: mmo...@google.com [mailto:mmo...@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
mailto:agri...@chromium.org>>
wrote:
> On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny
> mailto:mmo...@chromium.org>>
> wrote:
>
> > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve
> > mailto:agri...@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
> > > mailto:mmo...@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
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
wrote:
> On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny
> wrote:
>
> > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve
> > 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
> > 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 , 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 , they should still use plugin ID
> > >
> >
> > Nit: why? (and config.xml ) 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.
> 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
> 3. Install it
>
> I don't think we can do the validation step if we allow package-name within
> . 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,
Re: Schedule for npm transition
On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny wrote:
> On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve
> 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
> 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 , 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 , they should still use plugin ID
> >
>
> Nit: why? (and config.xml ) 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.
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
3. Install it
I don't think we can do the validation step if we allow package-name within
. 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
> > > wrote:
> >
Re: Schedule for npm transition
On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve
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 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 , they should still use plugin ID
>
Nit: why? (and config.xml ) 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
> > wrote:
> >
> > > Going to try and summarize my concerns with the proposal here:
> > >
> > > On Wed, Feb 11, 2015 at 2:39 PM, Steven Gill
> > > 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
Re: Schedule for npm transition
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 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 , 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
> wrote:
>
> > Going to try and summarize my concerns with the proposal here:
> >
> > On Wed, Feb 11, 2015 at 2:39 PM, Steven Gill
> > 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. within plugin.xml.
> > 2. 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
> > > 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 >
> > > > wrote:
> >
Re: Schedule for npm transition
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 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 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 >> 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 >> > 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-unsubscr...@cordova.apache.org >> > > For additional commands, e-mail: dev-h...@cordova.apache.org >> > > >> > > >> > >> -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Schedule for npm transition
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 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. within plugin.xml. > 2. within config.xml (for cordova plugin restore). > 3. within config.xml (or some other source of metadata) for a > 'cloud' Cordova build system. > > Thanks, > Leo > > -Original Message- > From: Shazron [mailto:shaz...@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 > 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 > > 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.treggi...@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:stevengil...@gmail.com] > >>>> Sent: Wednesday, February 11, 2015 11:40 AM > >>>> To: dev@cordova.apache.org > >>>> Subject: Re: Schedule for npm transition &g
RE: Schedule for npm transition
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. within plugin.xml. 2. within config.xml (for cordova plugin restore). 3. within config.xml (or some other source of metadata) for a 'cloud' Cordova build system. Thanks, Leo -Original Message- From: Shazron [mailto:shaz...@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 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 > 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 >>> 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:stevengil...@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"
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 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 > 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 >>> 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:stevengil...@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 >>>> 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 >>>>> wrote: >>>>> >>>>> We don't have one yet but we should pick dates soon. >>>>>> >>>>>> How abou
Re: Schedule for npm transition
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 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 >> 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:stevengil...@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 >>> 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 >>>> 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 de
Re: Schedule for npm transition
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 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:stevengil...@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 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 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 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-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Schedule for npm transition
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 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-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Schedule for npm transition
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 wrote: > Going to try and summarize my concerns with the proposal here: > > On Wed, Feb 11, 2015 at 2:39 PM, Steven Gill > 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. within plugin.xml. > 2. 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 > > 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 > > > 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.er...@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-unsubscr...@cordova.apache.org > > > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > > > > > > > > > > > > >
Re: Schedule for npm transition
Going to try and summarize my concerns with the proposal here: On Wed, Feb 11, 2015 at 2:39 PM, Steven Gill 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. within plugin.xml. 2. 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 > 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 > > 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 > > > 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-unsubscr...@cordova.apache.org > > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > > > > > > >
Re: Schedule for npm transition
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 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 > 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:stevengil...@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 >> 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 >> > 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 > > >> > > 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-unsubscr...@cordova.apache.org >> > > > For additional commands, e-mail: dev-h...@cordova.apache.org >> > > > >> > > > >> > > >> > >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> For additional commands, e-mail: dev-h...@cordova.apache.org >> >> >
Re: Schedule for npm transition
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 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:stevengil...@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 > 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 > > 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 > > > 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-unsubscr...@cordova.apache.org > > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
RE: Schedule for npm transition
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:stevengil...@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 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 > 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 > > 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-unsubscr...@cordova.apache.org > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
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 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 > 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 > > 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-unsubscr...@cordova.apache.org > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > >
Re: Schedule for npm transition
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 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 > 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-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > >
Re: Schedule for npm transition
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 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-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
