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 <leo.treggi...@intel.com> wrote:
> I have another question which I don't remember being discussed. > > Will older versions of the core plugins be published in NPM? I ask > because existing user projects may reference previous versions of plugins > and may want to be able to continue to fetch them for quite some time. > This is separate from the 'mapper' functionality. E.g. will a user be able > to request cordova-plugin-camera@0.3.4? Note that I see that the current > version is 0.3.5, and I don't actually know how old 0.3.4 is. > > These versioned references can come from a number of places including (as > Andrew pointed out and with one addition from me): > 1. <dependency> within plugin.xml. > 2. <plugin> within config.xml (for cordova plugin restore). > 3. <plugin> within config.xml (or some other source of metadata) for a > 'cloud' Cordova build system. > > Thanks, > Leo > > -----Original Message----- > From: Shazron [mailto: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 <stevengil...@gmail.com> > wrote: > > Mapper: https://github.com/stevengill/cordova-registry-mapper > > > > Mapper would be a dependency of cordova-lib. We would use it during > cordova > > plugin add/rm to map old id's to new name. > > > > We can look at extending CPR readonly phase but I fear we may have to > deal > > with migrating it to a different provider if want to extend its life. I > am > > not looking forward to dealing with that. > > > > In terms of package-name/package-id, we have been discussing it for > weeks. > > I am not a fan of the flip flopping on this issue and it is seriously > > holding up us moving forward with this. Michal did a great job explaining > > how the mapper could be integrated to handle the workflows. > > > > > > > > On Wed, Feb 11, 2015 at 3:20 PM, Gorkem Ercan <gorkem.er...@gmail.com> > > wrote: > > > >> > >> > >> On 11 Feb 2015, at 15:50, Michal Mocny wrote: > >> > >> Leo, restore will still work. The only information stored in the saves > >>> list is a set of plugin ids (and versions?). Restoring will go through > >>> the > >>> steps Steve outlines above, and either download from CPR or be mapped > >>> automatically to the npm equivalent. After the deprecation cutoff, > >>> plugins > >>> that aren't in the mapper may fail to restore -- so we could improve > the > >>> > >> > >> Any ideas what that mapper will look like? part of CLI, online service? > >> > >> > >> > >> rollout plan by starting to warn users adding plugins that still fetch > >>> from > >>> CPR. > >>> > >>> -Michal > >>> > >>> On Wed, Feb 11, 2015 at 2:58 PM, Treggiari, Leo < > leo.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 > >>>> > >>>> 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/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3 > >>>> OXmP-9DpYkcmfs/edit?usp=sharing > >>>> > >>>>> > >>>>>> - Need to start educating plugin developers to publish to npm as > well > >>>>>> > >>>>> as > >>>> > >>>>> CPR for next three months. (blog post) > >>>>>> - Need to educate users to install plugins via new names (if > >>>>>> > >>>>> package-name > >>>>> > >>>>>> is different than id). Our core plugins are being renamed from > >>>>>> org.apache.cordova.device to cordova-plugin-device > >>>>>> - Inform devs who are working with registry directly to pull plugins > >>>>>> > >>>>> from > >>>> > >>>>> npm instead of CPR. After 3 months, CPR plugins will start to become > >>>>>> > >>>>> out > >>>> > >>>>> of > >>>>> > >>>>>> date compared to npm versions. > >>>>>> > >>>>>> Our next plugins release (after the one currently ongoing) will be > >>>>>> published to npm as well as cpr. > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Wed, Feb 11, 2015 at 9:10 AM, Gorkem Ercan < > gorkem.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 > >>>> > >>>> > >>>> > >> --------------------------------------------------------------------- > >> 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 > >
