; is ok if the major number is not zero, and a number means
>> >>> something
>> >>> >> > that
>> >>> >> > > > can be use in production.
>> >>> &g
gt;> >> > > > declaring and resolving dependencies, plugin.xml schema,
> >>> >> > > > browersify/bootstrapjs, we could say that this consider an
> API
> >>> for
> >>> >> the
> >>> >> > > > plugin.
> &
;>> they
>>> >> > are
>>> >> > > > manage, we can take an opportunity to take the developers
>>> attention
>>> >> > with
>>> >> > > > the major version number change to easy distinguish that there
>>> >> > somethin
ekend pointed out that people
>> are
>> >> in
>> >> > > fact
>> >> > > > > pinning versions in plugin dependencies to avoid unexpected
>> >> > regressions
>> >> > > > or
>> >> > > > >
t; >> > > > 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
> 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:
> > > > >
> > > > >
> > &g
ed 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
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
ort 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 an
-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
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 i
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 yo
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 wo
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
>
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
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
ova 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@c
..@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, Steve
t;> 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 loc
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
>
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 w
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
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
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 wo
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 n
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: R
e 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
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
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,
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/
31 matches
Mail list logo
