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 <leo.treggi...@intel.com> wrote: > The proposal contains suggestions, alternatives and comments. > > > > https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP-9DpYkcmfs/edit?usp=sharing > > When will there be a final version that is the official plan? > > One other question: Soon we will have optional 'save' of plugin metadata > in config.xml. When CPR is turned off, there will be saved metadata which > is no longer valid - i.e. a restore will fail. This is because the 'name' > used to fetch a plugin (cordova-plugin-device) as well as the location will > change. Is there anything that can be done to mitigate that? Is the name > change really necessary - why can't we stick with the current names? > > Thanks, > Leo > > -----Original Message----- > From: Steven Gill [mailto: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 <mmo...@chromium.org> > wrote: > > > Steve, npm fetch default only affects plugins that use same name in both > > places, right? > > > > If we create cordova-plugin-device today, and tell users to start using > > cordova plugin add cordova-plugin-device, then we will get much user > > feedback on npm fetching far before May 18th, right? > > > > On Wed, Feb 11, 2015 at 1:09 PM, Steven Gill <stevengil...@gmail.com> > > wrote: > > > > > We don't have one yet but we should pick dates soon. > > > > > > How about: > > > > > > CPR Switch to read only: Monday, May 18th > > > NPM fetch becomes default: Monday, May 18th > > > CPR offline: Monday, August 17th > > > > > > Based on the following proposal: > > > > > > > > > https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP-9DpYkcmfs/edit?usp=sharing > > > > > > - Need to start educating plugin developers to publish to npm as well > as > > > CPR for next three months. (blog post) > > > - Need to educate users to install plugins via new names (if > > package-name > > > is different than id). Our core plugins are being renamed from > > > org.apache.cordova.device to cordova-plugin-device > > > - Inform devs who are working with registry directly to pull plugins > from > > > npm instead of CPR. After 3 months, CPR plugins will start to become > out > > of > > > date compared to npm versions. > > > > > > Our next plugins release (after the one currently ongoing) will be > > > published to npm as well as cpr. > > > > > > > > > > > > On Wed, Feb 11, 2015 at 9:10 AM, Gorkem Ercan <gorkem.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 > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
