cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Schedule for npm transition
Date Sat, 14 Feb 2015 00:50:19 GMT
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.treggiari@intel.com>
wrote:

> I have another question which I don't remember being discussed.
>
> Will older versions of the core plugins be published in NPM?  I ask
> because existing user projects may reference previous versions of plugins
> and may want to be able to continue to fetch them for quite some time.
> This is separate from the 'mapper' functionality.  E.g. will a user be able
> to request cordova-plugin-camera@0.3.4?  Note that I see that the current
> version is 0.3.5, and I don't actually know how old 0.3.4 is.
>
> These versioned references can come from a number of places including (as
> Andrew pointed out and with one addition from me):
> 1. <dependency> within plugin.xml.
> 2. <plugin> within config.xml (for cordova plugin restore).
> 3. <plugin> within config.xml (or some other source of metadata) for a
> 'cloud' Cordova build system.
>
> Thanks,
> Leo
>
> -----Original Message-----
> From: Shazron [mailto:shazron@gmail.com]
> Sent: Wednesday, February 11, 2015 3:48 PM
> To: dev@cordova.apache.org
> Subject: Re: Schedule for npm transition
>
> I agree with Steve to move forward with this. The package name
> rationale was already discussed during the hangout, and we all agreed.
>
> On Wed, Feb 11, 2015 at 3:43 PM, Steven Gill <stevengill97@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.ercan@gmail.com>
> > wrote:
> >
> >>
> >>
> >> On 11 Feb 2015, at 15:50, Michal Mocny wrote:
> >>
> >>  Leo, restore will still work.  The only information stored in the saves
> >>> list is a set of plugin ids (and versions?).  Restoring will go through
> >>> the
> >>> steps Steve outlines above, and either download from CPR or be mapped
> >>> automatically to the npm equivalent.  After the deprecation cutoff,
> >>> plugins
> >>> that aren't in the mapper may fail to restore -- so we could improve
> the
> >>>
> >>
> >> Any ideas what that mapper will look like? part of CLI, online service?
> >>
> >>
> >>
> >>  rollout plan by starting to warn users adding plugins that still fetch
> >>> from
> >>> CPR.
> >>>
> >>> -Michal
> >>>
> >>> On Wed, Feb 11, 2015 at 2:58 PM, Treggiari, Leo <
> leo.treggiari@intel.com>
> >>> wrote:
> >>>
> >>>  The proposal contains suggestions, alternatives and comments.
> >>>>
> >>>>
> >>>>>  https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3
> >>>> OXmP-9DpYkcmfs/edit?usp=sharing
> >>>>
> >>>> When will there be a final version that is the official plan?
> >>>>
> >>>> One other question:  Soon we will have optional 'save' of plugin
> metadata
> >>>> in config.xml.  When CPR is turned off, there will be saved metadata
> >>>> which
> >>>> is no longer valid - i.e. a restore will fail.  This is because the
> >>>> 'name'
> >>>> used to fetch a plugin (cordova-plugin-device) as well as the location
> >>>> will
> >>>> change.   Is there anything that can be done to mitigate that?  Is the
> >>>> name
> >>>> change really necessary - why can't we stick with the current names?
> >>>>
> >>>> Thanks,
> >>>> Leo
> >>>>
> >>>> -----Original Message-----
> >>>> From: Steven Gill [mailto:stevengill97@gmail.com]
> >>>> Sent: Wednesday, February 11, 2015 11:40 AM
> >>>> To: dev@cordova.apache.org
> >>>> Subject: Re: Schedule for npm transition
> >>>>
> >>>> Correct! For the first 3 months, all requests will hit CPR first, if
> CPR
> >>>> fails, we will try to fetch from npm.
> >>>>
> >>>> If users run "cordova plugin add cordova-plugin-device", it would hit
> >>>> CPR,
> >>>> fail, go to npm, succeed.
> >>>>
> >>>> If we use the mapper module, "cordova plugin add
> >>>> org.apache.cordova.device" would be converted to
> cordova-plugin-device,
> >>>> hit
> >>>> CPR, fail, go to npm, succeed.
> >>>>
> >>>> After 3 months, "cordova plugin add cordova-plugin-device" would hit
> npm
> >>>> first and succeed.
> >>>>
> >>>> We want to use these 3 months to get our developers to update their
> tools
> >>>> and use the new names for plugins to install.
> >>>>
> >>>> On Wed, Feb 11, 2015 at 10:36 AM, Michal Mocny <mmocny@chromium.org>
> >>>> wrote:
> >>>>
> >>>>  Steve, npm fetch default only affects plugins that use same name in
> both
> >>>>> places, right?
> >>>>>
> >>>>> If we create cordova-plugin-device today, and tell users to start
> using
> >>>>> cordova plugin add cordova-plugin-device, then we will get much
user
> >>>>> feedback on npm fetching far before May 18th, right?
> >>>>>
> >>>>> On Wed, Feb 11, 2015 at 1:09 PM, Steven Gill <stevengill97@gmail.com
> >
> >>>>> wrote:
> >>>>>
> >>>>>  We don't have one yet but we should pick dates soon.
> >>>>>>
> >>>>>> How about:
> >>>>>>
> >>>>>> CPR Switch to read only: Monday, May 18th
> >>>>>> NPM fetch becomes default: Monday, May 18th
> >>>>>> CPR offline: Monday, August 17th
> >>>>>>
> >>>>>> Based on the following proposal:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>  https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3
> >>>> OXmP-9DpYkcmfs/edit?usp=sharing
> >>>>
> >>>>>
> >>>>>> - Need to start educating plugin developers to publish to npm
as
> well
> >>>>>>
> >>>>> as
> >>>>
> >>>>> CPR for next three months. (blog post)
> >>>>>> - Need to educate users to install plugins via new names (if
> >>>>>>
> >>>>> package-name
> >>>>>
> >>>>>> is different than id). Our core plugins are being renamed from
> >>>>>> org.apache.cordova.device to cordova-plugin-device
> >>>>>> - Inform devs who are working with registry directly to pull
plugins
> >>>>>>
> >>>>> from
> >>>>
> >>>>> npm instead of CPR. After 3 months, CPR plugins will start to become
> >>>>>>
> >>>>> out
> >>>>
> >>>>> of
> >>>>>
> >>>>>> date compared to npm versions.
> >>>>>>
> >>>>>> Our next plugins release (after the one currently ongoing) will
be
> >>>>>> published to npm as well as cpr.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Feb 11, 2015 at 9:10 AM, Gorkem Ercan <
> gorkem.ercan@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>
> >>>>>>> Is there a determined calendar for the npm move of the plugins?
> >>>>>>> I think the scheduling of the transition is crucial for
those who
> are
> >>>>>>> using the plugin registry directly.
> >>>>>>> --
> >>>>>>> Gorkem
> >>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >>>>
> >>>>
> >>>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message