Re: plugins release?

[Jan Piotrowski]

Julio, I would be happy to pair with you on some plugin releases.

As you already noticed, the release processes via coho need some
serious work now that we are on GitHub issues instead of JIRA, so we
have some additional work ahead of us.

First step would be to identify which plugin to start with.
(I suggest selecting just 1 and seeing that through, then continue
with more if/when we are successful).

@Oliver: What you wrote mainly applies to the platforms - the plugin
release process should be independent from that. But we will keep that
in mind of course.

J

Am Di., 16. Okt. 2018 um 13:34 Uhr schrieb Oliver Salzburg
:
>
> I believe the issue with the pending releases is not that nobody is
> performing the release task. There are still implementation details
> being worked on if I'm not mistaken.
>
> The next release will supposedly introduce several major breaking
> changes, which have to be prepared for thoroughly.
>
> On 2018-10-13 22:02, julio cesar sanchez wrote:
> > Today I was checking github issues and noticed that a lot of them were
> > supposedly fixed already, but people are reporting them again as we have
> > not done a release since April and they are using the latest release and
> > not master.
> >
> > So, is anybody willing to do a release? If not I can try, but last time I
> > tried I wasn't able to finish it because of some problem with coho.
> >
> > Also, related to coho, it supposedly creates a JIRA issue, but that's not
> > possible anymore, so should we manually create a release issue per plugin?
> > Or patch coho to automatically create them? (if possible).
> > How are you doing it since we switched to github issues? (cc Chris as I
> > think you did most/all releases since then)
> >
>
>
> -
> 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: plugins release?

[Oliver Salzburg]

I believe the issue with the pending releases is not that nobody is 
performing the release task. There are still implementation details 
being worked on if I'm not mistaken.


The next release will supposedly introduce several major breaking 
changes, which have to be prepared for thoroughly.


On 2018-10-13 22:02, julio cesar sanchez wrote:

Today I was checking github issues and noticed that a lot of them were
supposedly fixed already, but people are reporting them again as we have
not done a release since April and they are using the latest release and
not master.

So, is anybody willing to do a release? If not I can try, but last time I
tried I wasn't able to finish it because of some problem with coho.

Also, related to coho, it supposedly creates a JIRA issue, but that's not
possible anymore, so should we manually create a release issue per plugin?
Or patch coho to automatically create them? (if possible).
How are you doing it since we switched to github issues? (cc Chris as I
think you did most/all releases since then)




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

RE: Plugins release prep: Cherry-picking plugin updates

[Rob Paveza]

Steven, thanks so much for all your help getting the plugins released.

-Original Message-
From: Murat Sutunc [mailto:mura...@microsoft.com] 
Sent: Wednesday, May 6, 2015 1:42 PM
To: dev@cordova.apache.org
Subject: RE: Plugins release prep: Cherry-picking plugin updates

Hey, took me a while but we're good to go with:
Camera, device-motion, dialogs and vibration.
Thanks!

-Original Message-
From: Steven Gill [mailto:stevengil...@gmail.com]
Sent: Wednesday, May 6, 2015 12:16 PM
To: dev@cordova.apache.org
Subject: Re: Plugins release prep: Cherry-picking plugin updates

Sounds good. Thanks Rob

On Wed, May 6, 2015 at 12:04 PM, Rob Paveza 
wrote:

> Murat is still working on the merge to master for the Camera plugin.  
> I'll let you know when we're all squared away.
>
> -Original Message-
> From: Steven Gill [mailto:stevengil...@gmail.com]
> Sent: Wednesday, May 6, 2015 11:57 AM
> To: dev@cordova.apache.org
> Subject: Re: Plugins release prep: Cherry-picking plugin updates
>
> I haven't heard back. Should I move forward with those 5 plugins?
>
> file-transfer, device-motion, dialogs, vibration, and camera.
>
> I will update the process to support specific plugins release (instead 
> of all plugins) as I work through it.
>
>
> On Tue, May 5, 2015 at 12:29 PM, Jesse  wrote:
>
> > + file-transfer so we can resolve CB-8951
> >
> >
> > @purplecabbage
> > risingj.com
> >
> > On Tue, May 5, 2015 at 12:19 PM, Steven Gill 
> > 
> > wrote:
> >
> > > Hey guys,
> > >
> > > I can help you out. The process is designed for all plugins but it 
> > > is pretty easy to do it for just a few. I've done it many times.
> > >
> > > If changes are on master, they shouldn't be incomplete. Any known 
> > > problem with release the master branch of those plugins?
> > >
> > > We could cherry-pick, but it is just more work than probably required.
> > > Since we don't have release branches for plugins, just tags.
> > >
> > > If you guys merge changes into master, I can take over the release 
> > > or at least tell you the parts to modify in the release process to 
> > > make it
> > work.
> > >
> > > -Steve
> > >
> > > On Tue, May 5, 2015 at 11:44 AM, Rob Paveza 
> > > 
> > > wrote:
> > >
> > > > Hi all -
> > > >
> > > > I started a [discuss] thread about plugin updates last week,
> > effectively
> > > > saying that we wanted to take four JIRA items which are causing
> > problems
> > > > for Windows 10: CB-8926, CB-8928, CB-8930, and CB-8943.  Since 
> > > > Murat
> > is a
> > > > committer, he's actually trying to do the release.  We're 
> > > > looking at device-motion, dialogs, vibration, and camera.
> > > >
> > > > However, as we go through the [release process](
> > > >
> > >
> > https://github.com/apache/cordova-coho/blob/master/docs/plugins-rele
> > as
> > e-process.md
> > > ),
> > > > there are a lot of things that give us pause, specifically that 
> > > > we're
> > > going
> > > > to end up tagging each plugin rather than just the four.  We're 
> > > > also concerned that we'll bring in unstable or not-yet-completed 
> > > > changes
> > from
> > > > 'master' in some of the plugins.  Instead, we're trying to
> cherry-pick.
> > > >
> > > > So, we know that where the final state is supposed to be:
> > > > - Each plugin that we're updating gets a new tag with a 
> > > > build-version
> > > bump
> > > > - The branch that we submitted as the PR should become the new 
> > > > tag
> > (since
> > > > it was based on the previous release tag)
> > > > - Then we'll go on with the rest of the publish-to-NPM work, etc.
> > > >
> > > > Since all of the steps are automated, is there a straightforward 
> > > > way to cherry-pick the individual pieces that is known and has 
> > > > been used
> > before?
> > > > Or are we in new territory?
> > > >
> > > > Thanks!
> > > > -Rob and Murat
> > > >
> > > > 
> > > > --
> > > > --- 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

RE: Plugins release prep: Cherry-picking plugin updates

[Murat Sutunc]

Hey, took me a while but we're good to go with:
Camera, device-motion, dialogs and vibration.
Thanks!

-Original Message-
From: Steven Gill [mailto:stevengil...@gmail.com] 
Sent: Wednesday, May 6, 2015 12:16 PM
To: dev@cordova.apache.org
Subject: Re: Plugins release prep: Cherry-picking plugin updates

Sounds good. Thanks Rob

On Wed, May 6, 2015 at 12:04 PM, Rob Paveza 
wrote:

> Murat is still working on the merge to master for the Camera plugin.  
> I'll let you know when we're all squared away.
>
> -Original Message-
> From: Steven Gill [mailto:stevengil...@gmail.com]
> Sent: Wednesday, May 6, 2015 11:57 AM
> To: dev@cordova.apache.org
> Subject: Re: Plugins release prep: Cherry-picking plugin updates
>
> I haven't heard back. Should I move forward with those 5 plugins?
>
> file-transfer, device-motion, dialogs, vibration, and camera.
>
> I will update the process to support specific plugins release (instead 
> of all plugins) as I work through it.
>
>
> On Tue, May 5, 2015 at 12:29 PM, Jesse  wrote:
>
> > + file-transfer so we can resolve CB-8951
> >
> >
> > @purplecabbage
> > risingj.com
> >
> > On Tue, May 5, 2015 at 12:19 PM, Steven Gill 
> > 
> > wrote:
> >
> > > Hey guys,
> > >
> > > I can help you out. The process is designed for all plugins but it 
> > > is pretty easy to do it for just a few. I've done it many times.
> > >
> > > If changes are on master, they shouldn't be incomplete. Any known 
> > > problem with release the master branch of those plugins?
> > >
> > > We could cherry-pick, but it is just more work than probably required.
> > > Since we don't have release branches for plugins, just tags.
> > >
> > > If you guys merge changes into master, I can take over the release 
> > > or at least tell you the parts to modify in the release process to 
> > > make it
> > work.
> > >
> > > -Steve
> > >
> > > On Tue, May 5, 2015 at 11:44 AM, Rob Paveza 
> > > 
> > > wrote:
> > >
> > > > Hi all -
> > > >
> > > > I started a [discuss] thread about plugin updates last week,
> > effectively
> > > > saying that we wanted to take four JIRA items which are causing
> > problems
> > > > for Windows 10: CB-8926, CB-8928, CB-8930, and CB-8943.  Since 
> > > > Murat
> > is a
> > > > committer, he's actually trying to do the release.  We're 
> > > > looking at device-motion, dialogs, vibration, and camera.
> > > >
> > > > However, as we go through the [release process](
> > > >
> > >
> > https://github.com/apache/cordova-coho/blob/master/docs/plugins-rele
> > as
> > e-process.md
> > > ),
> > > > there are a lot of things that give us pause, specifically that 
> > > > we're
> > > going
> > > > to end up tagging each plugin rather than just the four.  We're 
> > > > also concerned that we'll bring in unstable or not-yet-completed 
> > > > changes
> > from
> > > > 'master' in some of the plugins.  Instead, we're trying to
> cherry-pick.
> > > >
> > > > So, we know that where the final state is supposed to be:
> > > > - Each plugin that we're updating gets a new tag with a 
> > > > build-version
> > > bump
> > > > - The branch that we submitted as the PR should become the new 
> > > > tag
> > (since
> > > > it was based on the previous release tag)
> > > > - Then we'll go on with the rest of the publish-to-NPM work, etc.
> > > >
> > > > Since all of the steps are automated, is there a straightforward 
> > > > way to cherry-pick the individual pieces that is known and has 
> > > > been used
> > before?
> > > > Or are we in new territory?
> > > >
> > > > Thanks!
> > > > -Rob and Murat
> > > >
> > > > 
> > > > --
> > > > --- 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: Plugins release prep: Cherry-picking plugin updates

[Steven Gill]

Sounds good. Thanks Rob

On Wed, May 6, 2015 at 12:04 PM, Rob Paveza 
wrote:

> Murat is still working on the merge to master for the Camera plugin.  I'll
> let you know when we're all squared away.
>
> -Original Message-
> From: Steven Gill [mailto:stevengil...@gmail.com]
> Sent: Wednesday, May 6, 2015 11:57 AM
> To: dev@cordova.apache.org
> Subject: Re: Plugins release prep: Cherry-picking plugin updates
>
> I haven't heard back. Should I move forward with those 5 plugins?
>
> file-transfer, device-motion, dialogs, vibration, and camera.
>
> I will update the process to support specific plugins release (instead of
> all plugins) as I work through it.
>
>
> On Tue, May 5, 2015 at 12:29 PM, Jesse  wrote:
>
> > + file-transfer so we can resolve CB-8951
> >
> >
> > @purplecabbage
> > risingj.com
> >
> > On Tue, May 5, 2015 at 12:19 PM, Steven Gill 
> > wrote:
> >
> > > Hey guys,
> > >
> > > I can help you out. The process is designed for all plugins but it
> > > is pretty easy to do it for just a few. I've done it many times.
> > >
> > > If changes are on master, they shouldn't be incomplete. Any known
> > > problem with release the master branch of those plugins?
> > >
> > > We could cherry-pick, but it is just more work than probably required.
> > > Since we don't have release branches for plugins, just tags.
> > >
> > > If you guys merge changes into master, I can take over the release
> > > or at least tell you the parts to modify in the release process to
> > > make it
> > work.
> > >
> > > -Steve
> > >
> > > On Tue, May 5, 2015 at 11:44 AM, Rob Paveza
> > > 
> > > wrote:
> > >
> > > > Hi all -
> > > >
> > > > I started a [discuss] thread about plugin updates last week,
> > effectively
> > > > saying that we wanted to take four JIRA items which are causing
> > problems
> > > > for Windows 10: CB-8926, CB-8928, CB-8930, and CB-8943.  Since
> > > > Murat
> > is a
> > > > committer, he's actually trying to do the release.  We're looking
> > > > at device-motion, dialogs, vibration, and camera.
> > > >
> > > > However, as we go through the [release process](
> > > >
> > >
> > https://github.com/apache/cordova-coho/blob/master/docs/plugins-releas
> > e-process.md
> > > ),
> > > > there are a lot of things that give us pause, specifically that
> > > > we're
> > > going
> > > > to end up tagging each plugin rather than just the four.  We're
> > > > also concerned that we'll bring in unstable or not-yet-completed
> > > > changes
> > from
> > > > 'master' in some of the plugins.  Instead, we're trying to
> cherry-pick.
> > > >
> > > > So, we know that where the final state is supposed to be:
> > > > - Each plugin that we're updating gets a new tag with a
> > > > build-version
> > > bump
> > > > - The branch that we submitted as the PR should become the new tag
> > (since
> > > > it was based on the previous release tag)
> > > > - Then we'll go on with the rest of the publish-to-NPM work, etc.
> > > >
> > > > Since all of the steps are automated, is there a straightforward
> > > > way to cherry-pick the individual pieces that is known and has
> > > > been used
> > before?
> > > > Or are we in new territory?
> > > >
> > > > Thanks!
> > > > -Rob and Murat
> > > >
> > > > --
> > > > --- 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: Plugins release prep: Cherry-picking plugin updates

[Rob Paveza]

Murat is still working on the merge to master for the Camera plugin.  I'll let 
you know when we're all squared away.

-Original Message-
From: Steven Gill [mailto:stevengil...@gmail.com] 
Sent: Wednesday, May 6, 2015 11:57 AM
To: dev@cordova.apache.org
Subject: Re: Plugins release prep: Cherry-picking plugin updates

I haven't heard back. Should I move forward with those 5 plugins?

file-transfer, device-motion, dialogs, vibration, and camera.

I will update the process to support specific plugins release (instead of all 
plugins) as I work through it.


On Tue, May 5, 2015 at 12:29 PM, Jesse  wrote:

> + file-transfer so we can resolve CB-8951
>
>
> @purplecabbage
> risingj.com
>
> On Tue, May 5, 2015 at 12:19 PM, Steven Gill 
> wrote:
>
> > Hey guys,
> >
> > I can help you out. The process is designed for all plugins but it 
> > is pretty easy to do it for just a few. I've done it many times.
> >
> > If changes are on master, they shouldn't be incomplete. Any known 
> > problem with release the master branch of those plugins?
> >
> > We could cherry-pick, but it is just more work than probably required.
> > Since we don't have release branches for plugins, just tags.
> >
> > If you guys merge changes into master, I can take over the release 
> > or at least tell you the parts to modify in the release process to 
> > make it
> work.
> >
> > -Steve
> >
> > On Tue, May 5, 2015 at 11:44 AM, Rob Paveza 
> > 
> > wrote:
> >
> > > Hi all -
> > >
> > > I started a [discuss] thread about plugin updates last week,
> effectively
> > > saying that we wanted to take four JIRA items which are causing
> problems
> > > for Windows 10: CB-8926, CB-8928, CB-8930, and CB-8943.  Since 
> > > Murat
> is a
> > > committer, he's actually trying to do the release.  We're looking 
> > > at device-motion, dialogs, vibration, and camera.
> > >
> > > However, as we go through the [release process](
> > >
> >
> https://github.com/apache/cordova-coho/blob/master/docs/plugins-releas
> e-process.md
> > ),
> > > there are a lot of things that give us pause, specifically that 
> > > we're
> > going
> > > to end up tagging each plugin rather than just the four.  We're 
> > > also concerned that we'll bring in unstable or not-yet-completed 
> > > changes
> from
> > > 'master' in some of the plugins.  Instead, we're trying to cherry-pick.
> > >
> > > So, we know that where the final state is supposed to be:
> > > - Each plugin that we're updating gets a new tag with a 
> > > build-version
> > bump
> > > - The branch that we submitted as the PR should become the new tag
> (since
> > > it was based on the previous release tag)
> > > - Then we'll go on with the rest of the publish-to-NPM work, etc.
> > >
> > > Since all of the steps are automated, is there a straightforward 
> > > way to cherry-pick the individual pieces that is known and has 
> > > been used
> before?
> > > Or are we in new territory?
> > >
> > > Thanks!
> > > -Rob and Murat
> > >
> > > --
> > > --- 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: Plugins release prep: Cherry-picking plugin updates

[Steven Gill]

I haven't heard back. Should I move forward with those 5 plugins?

file-transfer, device-motion, dialogs, vibration, and camera.

I will update the process to support specific plugins release (instead of
all plugins) as I work through it.


On Tue, May 5, 2015 at 12:29 PM, Jesse  wrote:

> + file-transfer so we can resolve CB-8951
>
>
> @purplecabbage
> risingj.com
>
> On Tue, May 5, 2015 at 12:19 PM, Steven Gill 
> wrote:
>
> > Hey guys,
> >
> > I can help you out. The process is designed for all plugins but it is
> > pretty easy to do it for just a few. I've done it many times.
> >
> > If changes are on master, they shouldn't be incomplete. Any known problem
> > with release the master branch of those plugins?
> >
> > We could cherry-pick, but it is just more work than probably required.
> > Since we don't have release branches for plugins, just tags.
> >
> > If you guys merge changes into master, I can take over the release or at
> > least tell you the parts to modify in the release process to make it
> work.
> >
> > -Steve
> >
> > On Tue, May 5, 2015 at 11:44 AM, Rob Paveza 
> > wrote:
> >
> > > Hi all -
> > >
> > > I started a [discuss] thread about plugin updates last week,
> effectively
> > > saying that we wanted to take four JIRA items which are causing
> problems
> > > for Windows 10: CB-8926, CB-8928, CB-8930, and CB-8943.  Since Murat
> is a
> > > committer, he's actually trying to do the release.  We're looking at
> > > device-motion, dialogs, vibration, and camera.
> > >
> > > However, as we go through the [release process](
> > >
> >
> https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md
> > ),
> > > there are a lot of things that give us pause, specifically that we're
> > going
> > > to end up tagging each plugin rather than just the four.  We're also
> > > concerned that we'll bring in unstable or not-yet-completed changes
> from
> > > 'master' in some of the plugins.  Instead, we're trying to cherry-pick.
> > >
> > > So, we know that where the final state is supposed to be:
> > > - Each plugin that we're updating gets a new tag with a build-version
> > bump
> > > - The branch that we submitted as the PR should become the new tag
> (since
> > > it was based on the previous release tag)
> > > - Then we'll go on with the rest of the publish-to-NPM work, etc.
> > >
> > > Since all of the steps are automated, is there a straightforward way to
> > > cherry-pick the individual pieces that is known and has been used
> before?
> > > Or are we in new territory?
> > >
> > > Thanks!
> > > -Rob and Murat
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
> >
>

Re: Plugins release prep: Cherry-picking plugin updates

[Jesse]

+ file-transfer so we can resolve CB-8951


@purplecabbage
risingj.com

On Tue, May 5, 2015 at 12:19 PM, Steven Gill  wrote:

> Hey guys,
>
> I can help you out. The process is designed for all plugins but it is
> pretty easy to do it for just a few. I've done it many times.
>
> If changes are on master, they shouldn't be incomplete. Any known problem
> with release the master branch of those plugins?
>
> We could cherry-pick, but it is just more work than probably required.
> Since we don't have release branches for plugins, just tags.
>
> If you guys merge changes into master, I can take over the release or at
> least tell you the parts to modify in the release process to make it work.
>
> -Steve
>
> On Tue, May 5, 2015 at 11:44 AM, Rob Paveza 
> wrote:
>
> > Hi all -
> >
> > I started a [discuss] thread about plugin updates last week, effectively
> > saying that we wanted to take four JIRA items which are causing problems
> > for Windows 10: CB-8926, CB-8928, CB-8930, and CB-8943.  Since Murat is a
> > committer, he's actually trying to do the release.  We're looking at
> > device-motion, dialogs, vibration, and camera.
> >
> > However, as we go through the [release process](
> >
> https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md
> ),
> > there are a lot of things that give us pause, specifically that we're
> going
> > to end up tagging each plugin rather than just the four.  We're also
> > concerned that we'll bring in unstable or not-yet-completed changes from
> > 'master' in some of the plugins.  Instead, we're trying to cherry-pick.
> >
> > So, we know that where the final state is supposed to be:
> > - Each plugin that we're updating gets a new tag with a build-version
> bump
> > - The branch that we submitted as the PR should become the new tag (since
> > it was based on the previous release tag)
> > - Then we'll go on with the rest of the publish-to-NPM work, etc.
> >
> > Since all of the steps are automated, is there a straightforward way to
> > cherry-pick the individual pieces that is known and has been used before?
> > Or are we in new territory?
> >
> > Thanks!
> > -Rob and Murat
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>

Re: Plugins release prep: Cherry-picking plugin updates

[Steven Gill]

Hey guys,

I can help you out. The process is designed for all plugins but it is
pretty easy to do it for just a few. I've done it many times.

If changes are on master, they shouldn't be incomplete. Any known problem
with release the master branch of those plugins?

We could cherry-pick, but it is just more work than probably required.
Since we don't have release branches for plugins, just tags.

If you guys merge changes into master, I can take over the release or at
least tell you the parts to modify in the release process to make it work.

-Steve

On Tue, May 5, 2015 at 11:44 AM, Rob Paveza 
wrote:

> Hi all -
>
> I started a [discuss] thread about plugin updates last week, effectively
> saying that we wanted to take four JIRA items which are causing problems
> for Windows 10: CB-8926, CB-8928, CB-8930, and CB-8943.  Since Murat is a
> committer, he's actually trying to do the release.  We're looking at
> device-motion, dialogs, vibration, and camera.
>
> However, as we go through the [release process](
> https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md),
> there are a lot of things that give us pause, specifically that we're going
> to end up tagging each plugin rather than just the four.  We're also
> concerned that we'll bring in unstable or not-yet-completed changes from
> 'master' in some of the plugins.  Instead, we're trying to cherry-pick.
>
> So, we know that where the final state is supposed to be:
> - Each plugin that we're updating gets a new tag with a build-version bump
> - The branch that we submitted as the PR should become the new tag (since
> it was based on the previous release tag)
> - Then we'll go on with the rest of the publish-to-NPM work, etc.
>
> Since all of the steps are automated, is there a straightforward way to
> cherry-pick the individual pieces that is known and has been used before?
> Or are we in new territory?
>
> Thanks!
> -Rob and Murat
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Plugins Release blog post draft

[Steven Gill]

Fixed! Thanks


On Fri, Aug 8, 2014 at 11:58 AM, Axel Nennker  wrote:

> Typo in
>
> Ubuntu: fix compler warnings
>
> Axel
> Am 08.08.2014 00:18 schrieb "Steven Gill" :
>
> > Please review and send PRs for changes. I can also add you to the repo if
> > you want to edit directly on github and not worry about the PR.
> >
> >
> >
> https://github.com/cordova/apache-blog-posts/blob/master/2014-08-08-plugins-release.md
> >
>

Re: Plugins Release blog post draft

[Axel Nennker]

Typo in

Ubuntu: fix compler warnings

Axel
Am 08.08.2014 00:18 schrieb "Steven Gill" :

> Please review and send PRs for changes. I can also add you to the repo if
> you want to edit directly on github and not worry about the PR.
>
>
> https://github.com/cordova/apache-blog-posts/blob/master/2014-08-08-plugins-release.md
>

Re: Plugins Release blog post draft

[Steven Gill]

Hahaha. Michal, we pretty much only use it to preview blog posts & board
reports. I sent you an invite to it.




On Fri, Aug 8, 2014 at 9:57 AM, Bryan Higgins 
wrote:

> LGTM
>
>
> On Fri, Aug 8, 2014 at 8:22 AM, Michal Mocny  wrote:
>
> > wait wait, a cordova organization on github with push access!?  Thats
> like,
> > useful!  (and blasphemy)
> >
> >
> > On Thu, Aug 7, 2014 at 9:33 PM, Andrew Grieve 
> > wrote:
> >
> > > LGTM
> > >
> > >
> > > On Thu, Aug 7, 2014 at 7:17 PM, Steven Gill 
> > > wrote:
> > >
> > > > Please review and send PRs for changes. I can also add you to the
> repo
> > if
> > > > you want to edit directly on github and not worry about the PR.
> > > >
> > > >
> > > >
> > >
> >
> https://github.com/cordova/apache-blog-posts/blob/master/2014-08-08-plugins-release.md
> > > >
> > >
> >
>

Re: Plugins Release blog post draft

[Bryan Higgins]

LGTM


On Fri, Aug 8, 2014 at 8:22 AM, Michal Mocny  wrote:

> wait wait, a cordova organization on github with push access!?  Thats like,
> useful!  (and blasphemy)
>
>
> On Thu, Aug 7, 2014 at 9:33 PM, Andrew Grieve 
> wrote:
>
> > LGTM
> >
> >
> > On Thu, Aug 7, 2014 at 7:17 PM, Steven Gill 
> > wrote:
> >
> > > Please review and send PRs for changes. I can also add you to the repo
> if
> > > you want to edit directly on github and not worry about the PR.
> > >
> > >
> > >
> >
> https://github.com/cordova/apache-blog-posts/blob/master/2014-08-08-plugins-release.md
> > >
> >
>

Re: Plugins Release blog post draft

[Michal Mocny]

wait wait, a cordova organization on github with push access!?  Thats like,
useful!  (and blasphemy)


On Thu, Aug 7, 2014 at 9:33 PM, Andrew Grieve  wrote:

> LGTM
>
>
> On Thu, Aug 7, 2014 at 7:17 PM, Steven Gill 
> wrote:
>
> > Please review and send PRs for changes. I can also add you to the repo if
> > you want to edit directly on github and not worry about the PR.
> >
> >
> >
> https://github.com/cordova/apache-blog-posts/blob/master/2014-08-08-plugins-release.md
> >
>

Re: Plugins Release blog post draft

[Andrew Grieve]

LGTM


On Thu, Aug 7, 2014 at 7:17 PM, Steven Gill  wrote:

> Please review and send PRs for changes. I can also add you to the repo if
> you want to edit directly on github and not worry about the PR.
>
>
> https://github.com/cordova/apache-blog-posts/blob/master/2014-08-08-plugins-release.md
>

Re: Plugins Release Blog Post Review!

[Andrew Grieve]

Nice work. Clean up extended notes and added re-did call-out of file
changes: https://github.com/cordova/apache-blog-posts/pull/5


On Fri, Jun 6, 2014 at 7:36 PM, Steven Gill  wrote:

> Please review the blog post at
>
> https://github.com/cordova/apache-blog-posts/blob/master/2014-06-05-plugins-release.md
> .
>
>
> Send a pull request for changes. Or ask and I shall give you access to the
> repo.
>
> Once again, I would love some input on the notable changes section. Mainly,
> what else should I mention.
>
> -Steve
>

Re: Plugins Release!

[Andrew Grieve]

The docs are all there in the plugin repos now and removed from
cordova-docs. Even if Crowdin could detect moves, the files have mostly
been merged into one anyways. Hopefully the translations can be mostly
copy/pasted though...


On Tue, Feb 11, 2014 at 12:09 PM, Lisa Seacat DeLuca wrote:

> Right now the translations are pulled from the cordova-docs project edge
> files.  If we'll need to pull the files from a different location(s) we'll
> need to modify the scripts and push to our crowd translation service.
>  We'll have to ask our translators to go through and re-translate each of
> the files.  The system won't know that the files are the same when we
> change the directory structure despite the names remaining the same.  All
> this is doable.  Is the documentation for each plugin officially pulled
> into each of the plugin repos, yet?
>
>
> Lisa Seacat DeLuca
> Mobile Engineer | t: +415.787.4589 | 
> *ldel...@apache.org*| |
> *ldel...@us.ibm.com*  | 
> *lisaseacat.com*<http://www.lisaseacat.com/>| [image:
> follow @LisaSeacat on twitter] <http://www.twitter.com/LisaSeacat>| [image:
> follow Lisa Seacat DeLuca on linkedin]<http://www.linkedin.com/in/lisaseacat>
>
>
>
>
>
> From:    Andrew Grieve 
> To:dev 
> Date:02/11/2014 10:56 AM
> Subject:Re: Plugins Release!
> Sent by:agri...@google.com
> --
>
>
>
> For now, that's correct. Eventually, we'd like to have the docs in the
> plugins also include translations.
>
>
> On Tue, Feb 11, 2014 at 12:40 AM, Smith, Peter
> wrote:
>
> >
> > The site
> >
> http://cordova.apache.org/docs/en/edge/cordova_plugins_pluginapis.md.html#Plugin%20APIssays
> > 
> > Non-English translations of these plugin docs can be found by looking at
> > older versions of the Cordova documentation. Use the drop-down menu at
> the
> > very top-right of this site to switch versions.
> > 
> >
> > I assume the English version of the docs for the plugin is correct for
> the
> > latest version of that plugin.
> >
> > But IIUC doesn't that quote above mean (depending on plugin version
> > changes) that the non-English docs can't really be trusted anymore
> because
> > they are potentially incompatible with the actual latest plugin? It seems
> > like the site is basically saying "go to XXX where you will be able to
> see
> > some outdated non-English documentation". Is that helpful?
> >
> > -Original Message-
> > From: agri...@google.com [mailto:agri...@google.com ]
> On Behalf Of Andrew
> > Grieve
> > Sent: Tuesday, 11 February 2014 2:35 PM
> > To: dev
> > Subject: Re: Plugins Release!
> >
> > Feedback definitely welcome in this department.
> > For the 3.4.0 release, the main docs for plugins will look like:
> >
> >
> http://cordova.apache.org/docs/en/edge/cordova_plugins_pluginapis.md.html#Plugin%20APIs
> >
> >
> > On Mon, Feb 10, 2014 at 10:07 PM, Ray Camden  wrote:
> >
> > > Is that the plan for 'core' plugins too? Won't that make it difficult
> > > for someone to see PG features as a whole? Will there be an index of
> > > some sort to make it easier to browse perhaps?
> > >
> > > Sorry for all the questions - just thinking about this from the
> > > perspective of folks *not* on this list.
> > >
> > > 
> > > From: Shazron 
> > > Sent: Monday, February 10, 2014 7:28 PM
> > > To: dev@cordova.apache.org
> > > Subject: Re: Plugins Release!
> > >
> > > The docs should be in the repo for the plugin itself, under the docs
> > > folder:
> > > https://github.com/apache/cordova-plugin-camera/blob/master/doc/index.
> > > md
> > >
> > > We're moving the docs to the plugin repo itself I believe, to
> > > de-duplicate things.
> > >
> > >
> > > On Mon, Feb 10, 2014 at 5:14 PM, Ray Camden 
> wrote:
> > >
> > > >
> > >
> >
>
>

Re: Plugins Release!

[Lisa Seacat DeLuca]

Right now the translations are pulled from the cordova-docs project edge 
files.  If we'll need to pull the files from a different location(s) we'll 
need to modify the scripts and push to our crowd translation service. 
We'll have to ask our translators to go through and re-translate each of 
the files.  The system won't know that the files are the same when we 
change the directory structure despite the names remaining the same.  All 
this is doable.  Is the documentation for each plugin officially pulled 
into each of the plugin repos, yet? 


Lisa Seacat DeLuca
Mobile Engineer | t: +415.787.4589 | ldel...@apache.org | | 
ldel...@us.ibm.com | lisaseacat.com | | 





From:   Andrew Grieve 
To: dev 
Date:   02/11/2014 10:56 AM
Subject:    Re: Plugins Release!
Sent by:agri...@google.com



For now, that's correct. Eventually, we'd like to have the docs in the
plugins also include translations.


On Tue, Feb 11, 2014 at 12:40 AM, Smith, Peter
wrote:

>
> The site
> 
http://cordova.apache.org/docs/en/edge/cordova_plugins_pluginapis.md.html#Plugin%20APIssays

> 
> Non-English translations of these plugin docs can be found by looking at
> older versions of the Cordova documentation. Use the drop-down menu at 
the
> very top-right of this site to switch versions.
> 
>
> I assume the English version of the docs for the plugin is correct for 
the
> latest version of that plugin.
>
> But IIUC doesn't that quote above mean (depending on plugin version
> changes) that the non-English docs can't really be trusted anymore 
because
> they are potentially incompatible with the actual latest plugin? It 
seems
> like the site is basically saying "go to XXX where you will be able to 
see
> some outdated non-English documentation". Is that helpful?
>
> -Original Message-
> From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
> Grieve
> Sent: Tuesday, 11 February 2014 2:35 PM
> To: dev
> Subject: Re: Plugins Release!
>
> Feedback definitely welcome in this department.
> For the 3.4.0 release, the main docs for plugins will look like:
>
> 
http://cordova.apache.org/docs/en/edge/cordova_plugins_pluginapis.md.html#Plugin%20APIs

>
>
> On Mon, Feb 10, 2014 at 10:07 PM, Ray Camden  wrote:
>
> > Is that the plan for 'core' plugins too? Won't that make it difficult
> > for someone to see PG features as a whole? Will there be an index of
> > some sort to make it easier to browse perhaps?
> >
> > Sorry for all the questions - just thinking about this from the
> > perspective of folks *not* on this list.
> >
> > 
> > From: Shazron 
> > Sent: Monday, February 10, 2014 7:28 PM
> > To: dev@cordova.apache.org
> > Subject: Re: Plugins Release!
> >
> > The docs should be in the repo for the plugin itself, under the docs
> > folder:
> > https://github.com/apache/cordova-plugin-camera/blob/master/doc/index.
> > md
> >
> > We're moving the docs to the plugin repo itself I believe, to
> > de-duplicate things.
> >
> >
> > On Mon, Feb 10, 2014 at 5:14 PM, Ray Camden  
wrote:
> >
> > >
> >
>

Re: Plugins Release!

[Andrew Grieve]

For now, that's correct. Eventually, we'd like to have the docs in the
plugins also include translations.


On Tue, Feb 11, 2014 at 12:40 AM, Smith, Peter
wrote:

>
> The site
> http://cordova.apache.org/docs/en/edge/cordova_plugins_pluginapis.md.html#Plugin%20APIssays
> 
> Non-English translations of these plugin docs can be found by looking at
> older versions of the Cordova documentation. Use the drop-down menu at the
> very top-right of this site to switch versions.
> 
>
> I assume the English version of the docs for the plugin is correct for the
> latest version of that plugin.
>
> But IIUC doesn't that quote above mean (depending on plugin version
> changes) that the non-English docs can't really be trusted anymore because
> they are potentially incompatible with the actual latest plugin? It seems
> like the site is basically saying "go to XXX where you will be able to see
> some outdated non-English documentation". Is that helpful?
>
> -Original Message-
> From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
> Grieve
> Sent: Tuesday, 11 February 2014 2:35 PM
> To: dev
> Subject: Re: Plugins Release!
>
> Feedback definitely welcome in this department.
> For the 3.4.0 release, the main docs for plugins will look like:
>
> http://cordova.apache.org/docs/en/edge/cordova_plugins_pluginapis.md.html#Plugin%20APIs
>
>
> On Mon, Feb 10, 2014 at 10:07 PM, Ray Camden  wrote:
>
> > Is that the plan for 'core' plugins too? Won't that make it difficult
> > for someone to see PG features as a whole? Will there be an index of
> > some sort to make it easier to browse perhaps?
> >
> > Sorry for all the questions - just thinking about this from the
> > perspective of folks *not* on this list.
> >
> > 
> > From: Shazron 
> > Sent: Monday, February 10, 2014 7:28 PM
> > To: dev@cordova.apache.org
> > Subject: Re: Plugins Release!
> >
> > The docs should be in the repo for the plugin itself, under the docs
> > folder:
> > https://github.com/apache/cordova-plugin-camera/blob/master/doc/index.
> > md
> >
> > We're moving the docs to the plugin repo itself I believe, to
> > de-duplicate things.
> >
> >
> > On Mon, Feb 10, 2014 at 5:14 PM, Ray Camden  wrote:
> >
> > >
> >
>

RE: Plugins Release!

[Smith, Peter]

The site 
http://cordova.apache.org/docs/en/edge/cordova_plugins_pluginapis.md.html#Plugin%20APIs
 says

Non-English translations of these plugin docs can be found by looking at older 
versions of the Cordova documentation. Use the drop-down menu at the very 
top-right of this site to switch versions.


I assume the English version of the docs for the plugin is correct for the 
latest version of that plugin.

But IIUC doesn't that quote above mean (depending on plugin version changes) 
that the non-English docs can't really be trusted anymore because they are 
potentially incompatible with the actual latest plugin? It seems like the site 
is basically saying "go to XXX where you will be able to see some outdated 
non-English documentation". Is that helpful?

-Original Message-
From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve
Sent: Tuesday, 11 February 2014 2:35 PM
To: dev
Subject: Re: Plugins Release!

Feedback definitely welcome in this department.
For the 3.4.0 release, the main docs for plugins will look like:
http://cordova.apache.org/docs/en/edge/cordova_plugins_pluginapis.md.html#Plugin%20APIs


On Mon, Feb 10, 2014 at 10:07 PM, Ray Camden  wrote:

> Is that the plan for 'core' plugins too? Won't that make it difficult 
> for someone to see PG features as a whole? Will there be an index of 
> some sort to make it easier to browse perhaps?
>
> Sorry for all the questions - just thinking about this from the 
> perspective of folks *not* on this list.
>
> 
> From: Shazron 
> Sent: Monday, February 10, 2014 7:28 PM
> To: dev@cordova.apache.org
> Subject: Re: Plugins Release!
>
> The docs should be in the repo for the plugin itself, under the docs
> folder:
> https://github.com/apache/cordova-plugin-camera/blob/master/doc/index.
> md
>
> We're moving the docs to the plugin repo itself I believe, to 
> de-duplicate things.
>
>
> On Mon, Feb 10, 2014 at 5:14 PM, Ray Camden  wrote:
>
> >
>

RE: Plugins Release!

[Ray Camden]

Interesting. Um, I've got nothing to add here I guess. ;) I am curious to see 
what folks out there think.

From: agri...@google.com  on behalf of Andrew Grieve 

Sent: Monday, February 10, 2014 9:34 PM
To: dev
Subject: Re: Plugins Release!

Feedback definitely welcome in this department.
For the 3.4.0 release, the main docs for plugins will look like:
http://cordova.apache.org/docs/en/edge/cordova_plugins_pluginapis.md.html#Plugin%20APIs


On Mon, Feb 10, 2014 at 10:07 PM, Ray Camden  wrote:

Re: Plugins Release!

[Andrew Grieve]

Feedback definitely welcome in this department.
For the 3.4.0 release, the main docs for plugins will look like:
http://cordova.apache.org/docs/en/edge/cordova_plugins_pluginapis.md.html#Plugin%20APIs


On Mon, Feb 10, 2014 at 10:07 PM, Ray Camden  wrote:

> Is that the plan for 'core' plugins too? Won't that make it difficult for
> someone to see PG features as a whole? Will there be an index of some sort
> to make it easier to browse perhaps?
>
> Sorry for all the questions - just thinking about this from the
> perspective of folks *not* on this list.
>
> 
> From: Shazron 
> Sent: Monday, February 10, 2014 7:28 PM
> To: dev@cordova.apache.org
> Subject: Re: Plugins Release!
>
> The docs should be in the repo for the plugin itself, under the docs
> folder:
> https://github.com/apache/cordova-plugin-camera/blob/master/doc/index.md
>
> We're moving the docs to the plugin repo itself I believe, to de-duplicate
> things.
>
>
> On Mon, Feb 10, 2014 at 5:14 PM, Ray Camden  wrote:
>
> >
>

RE: Plugins Release!

[Ray Camden]

Is that the plan for 'core' plugins too? Won't that make it difficult for 
someone to see PG features as a whole? Will there be an index of some sort to 
make it easier to browse perhaps? 

Sorry for all the questions - just thinking about this from the perspective of 
folks *not* on this list.


From: Shazron 
Sent: Monday, February 10, 2014 7:28 PM
To: dev@cordova.apache.org
Subject: Re: Plugins Release!

The docs should be in the repo for the plugin itself, under the docs folder:
https://github.com/apache/cordova-plugin-camera/blob/master/doc/index.md

We're moving the docs to the plugin repo itself I believe, to de-duplicate
things.


On Mon, Feb 10, 2014 at 5:14 PM, Ray Camden  wrote:

> 

Re: Plugins Release!

[Shazron]

The docs should be in the repo for the plugin itself, under the docs folder:
https://github.com/apache/cordova-plugin-camera/blob/master/doc/index.md

We're moving the docs to the plugin repo itself I believe, to de-duplicate
things.


On Mon, Feb 10, 2014 at 5:14 PM, Ray Camden  wrote:

> Dumb question, but when I see things like this in the blog post:
>
> org.apache.cordova.camera
>
> CB-4919 firefox os quirks added and supported platforms list is updated
>
> Where is that actually documented? Since I've seen quirks listed in the
> main doc I assumed it would be there, but I do not see it here:
> http://cordova.apache.org/docs/en/3.3.0/cordova_camera_camera.md.html#Camera
>
> 
> From: Steven Gill 
> Sent: Monday, February 10, 2014 5:53 PM
> To: dev@cordova.apache.org
> Subject: Re: Plugins Release!
>
> shipped.
>
> http://cordova.apache.org/news/2014/02/10/plugins-release.html
>
>
> On Sat, Feb 8, 2014 at 8:43 AM, Andrew Grieve 
> wrote:
>
> > ship it.
> >
> >
> > On Fri, Feb 7, 2014 at 7:35 PM, Steven Gill 
> > wrote:
> >
> > > ship it?
> > >
>

RE: Plugins Release!

[Ray Camden]

Dumb question, but when I see things like this in the blog post:

org.apache.cordova.camera

CB-4919 firefox os quirks added and supported platforms list is updated

Where is that actually documented? Since I've seen quirks listed in the main 
doc I assumed it would be there, but I do not see it here: 
http://cordova.apache.org/docs/en/3.3.0/cordova_camera_camera.md.html#Camera


From: Steven Gill 
Sent: Monday, February 10, 2014 5:53 PM
To: dev@cordova.apache.org
Subject: Re: Plugins Release!

shipped.

http://cordova.apache.org/news/2014/02/10/plugins-release.html


On Sat, Feb 8, 2014 at 8:43 AM, Andrew Grieve  wrote:

> ship it.
>
>
> On Fri, Feb 7, 2014 at 7:35 PM, Steven Gill 
> wrote:
>
> > ship it?
> >

Re: Plugins Release!

[Steven Gill]

shipped.

http://cordova.apache.org/news/2014/02/10/plugins-release.html


On Sat, Feb 8, 2014 at 8:43 AM, Andrew Grieve  wrote:

> ship it.
>
>
> On Fri, Feb 7, 2014 at 7:35 PM, Steven Gill 
> wrote:
>
> > ship it?
> >
> >
> > On Fri, Feb 7, 2014 at 12:03 PM, Steven Gill 
> > wrote:
> >
> > > Thanks for the feedback Ian! Just waiting on the "SHIP IT"
> > >
> > > Updated blog below:
> > >
> > > ---
> > > layout: post
> > > author:
> > > name: Steve Gill
> > > url: https://twitter.com/stevesgill
> > > title:  "Plugins Release: Feb 7, 2014"
> > > categories: news
> > > tags: release
> > > ---
> > > The following plugins were updated today:
> > >
> > > * org.apache.cordova.battery-status@0.2.7
> > > * org.apache.cordova.camera@0.2.7
> > > * org.apache.cordova.console@0.2.7
> > > * org.apache.cordova.contacts@0.2.8
> > > * org.apache.cordova.device@0.2.8
> > > * org.apache.cordova.device-motion@0.2.6
> > > * org.apache.cordova.device-orientation@0.3.5
> > > * org.apache.cordova.dialogs@0.2.6
> > > * org.apache.cordova.file@1.0.0
> > > * org.apache.cordova.file-transfer@0.4.1
> > > * org.apache.cordova.geolocation@0.3.6
> > > * org.apache.cordova.globalization@0.2.6
> > > * org.apache.cordova.inappbrowser@0.3.1
> > > * org.apache.cordova.media@0.2.8
> > > * org.apache.cordova.media-capture@0.2.7
> > > * org.apache.cordova.network-information@0.2.7
> > > * org.apache.cordova.vibration@0.3.7
> > >
> > > The most noticeable changes in this release are to the File plugin. It
> > has
> > > been revamped to use a new URL scheme
> > > `cdvfile://localhost//`. These URLs are
> > > generated by all file operations, and are passed over the bridge to
> > native
> > > code. (This is in contrast to the previous version, which passed around
> > > absolute paths on the device filesystem).
> > >
> > > Most of these changes are to bring us more in line with the HTML
> > > Filesystem standard, although they will also allow us to extend the
> > > filesystem abstraction to cover new kinds of storage, both internal and
> > > external to devices.
> > >
> > > Other changes include:
> > > 
> > > * The file plugin is now much more modular. The "Filesystem" is now an
> > > abstract class that developers can subclass to write their own
> filesystem
> > > types.
> > > * Developers can use the existing filesystem types, or new types, to
> > > provide new filesystem roots for their applications. (No longer limited
> > to
> > > just persistent and temporary, or just a single directory for storage.)
> > > * Filesystem URLs paths are now relative to the filesystem root,
> helping
> > > to sandbox the filesystems and keep applications from stepping on each
> > > others' toes.
> > > * Application developers can now configure the file plugin to use a
> more
> > > sensible location for storing persistent files. On iOS, this means
> > storing
> > > files in the Library directory, rather than the Documents directory. On
> > > Android, it means using the application's internal storage directory
> > rather
> > > than the SD card partition. See the README file for information on
> > > configuring your applications.
> > > * Several other bugs have been fixed, and our test coverage has
> > increased.
> > >
> > > `org.apache.cordova.battery-status`
> > >
> > > * Add Tizen plugin support
> > >
> > > `org.apache.cordova.camera`
> > > * CB-4919 firefox os quirks added and supported platforms list is
> updated
> > > * getPicture via web activities
> > > * Documented quirk for CB-5335 + CB-5206 for WP7+8
> > > * reference the correct firefoxos implementation
> > > * [BlackBerry10] Add permission to access_shared
> > >
> > > `org.apache.cordova.console`
> > > * Native console needs to be called DebugConsole to avoid ambiguous
> > > reference. This commit requires the 3.4.0 version of the native class
> > > factory
> > > * CB-4718 fixed Console plugin not working on wp
> > >
> > > `org.apache.cordova.contacts`
> > > * [CB-3208] FFOS docs updated
> > > * CB-4590 - chooseContact in CDVContacts crashes app
> > >
> > > `org.apache.cordova.device`
> > >
> > > * Tizen support added
> > >
> > > `org.apache.cordova.device-motion`
> > >
> > > * Add Tizen support
> > >
> > > `org.apache.cordova.device-orientation`
> > > * [ubuntu] request sensors permission
> > > * [ubuntu] add missing files
> > > * Add support for Tizen.
> > > * FFOS info added
> > >
> > > `org.apache.cordova.dialogs`
> > > * no need to recreate the manifest.webapp file after each `cordova
> > > prepare` for FFOS
> > > * FFOS description added
> > >
> > > `org.apache.cordova.file`
> > > * CB-5974: Use safe 'Compatibility' mode by default
> > > * CB-5915: Add option for new persistent storage location for iOS
> > > * CB-5916: Add option for new persistent storage location for Android
> > > * Add default FS root to new FS objects
> > > * CB-5899: Make DirectoryReader.readEntries return properly formatted
> > > Entry objects
> > > * Add constructor params to FileUploadResult related to CB-2421
> > >

Re: Plugins Release!

[Andrew Grieve]

ship it.


On Fri, Feb 7, 2014 at 7:35 PM, Steven Gill  wrote:

> ship it?
>
>
> On Fri, Feb 7, 2014 at 12:03 PM, Steven Gill 
> wrote:
>
> > Thanks for the feedback Ian! Just waiting on the "SHIP IT"
> >
> > Updated blog below:
> >
> > ---
> > layout: post
> > author:
> > name: Steve Gill
> > url: https://twitter.com/stevesgill
> > title:  "Plugins Release: Feb 7, 2014"
> > categories: news
> > tags: release
> > ---
> > The following plugins were updated today:
> >
> > * org.apache.cordova.battery-status@0.2.7
> > * org.apache.cordova.camera@0.2.7
> > * org.apache.cordova.console@0.2.7
> > * org.apache.cordova.contacts@0.2.8
> > * org.apache.cordova.device@0.2.8
> > * org.apache.cordova.device-motion@0.2.6
> > * org.apache.cordova.device-orientation@0.3.5
> > * org.apache.cordova.dialogs@0.2.6
> > * org.apache.cordova.file@1.0.0
> > * org.apache.cordova.file-transfer@0.4.1
> > * org.apache.cordova.geolocation@0.3.6
> > * org.apache.cordova.globalization@0.2.6
> > * org.apache.cordova.inappbrowser@0.3.1
> > * org.apache.cordova.media@0.2.8
> > * org.apache.cordova.media-capture@0.2.7
> > * org.apache.cordova.network-information@0.2.7
> > * org.apache.cordova.vibration@0.3.7
> >
> > The most noticeable changes in this release are to the File plugin. It
> has
> > been revamped to use a new URL scheme
> > `cdvfile://localhost//`. These URLs are
> > generated by all file operations, and are passed over the bridge to
> native
> > code. (This is in contrast to the previous version, which passed around
> > absolute paths on the device filesystem).
> >
> > Most of these changes are to bring us more in line with the HTML
> > Filesystem standard, although they will also allow us to extend the
> > filesystem abstraction to cover new kinds of storage, both internal and
> > external to devices.
> >
> > Other changes include:
> > 
> > * The file plugin is now much more modular. The "Filesystem" is now an
> > abstract class that developers can subclass to write their own filesystem
> > types.
> > * Developers can use the existing filesystem types, or new types, to
> > provide new filesystem roots for their applications. (No longer limited
> to
> > just persistent and temporary, or just a single directory for storage.)
> > * Filesystem URLs paths are now relative to the filesystem root, helping
> > to sandbox the filesystems and keep applications from stepping on each
> > others' toes.
> > * Application developers can now configure the file plugin to use a more
> > sensible location for storing persistent files. On iOS, this means
> storing
> > files in the Library directory, rather than the Documents directory. On
> > Android, it means using the application's internal storage directory
> rather
> > than the SD card partition. See the README file for information on
> > configuring your applications.
> > * Several other bugs have been fixed, and our test coverage has
> increased.
> >
> > `org.apache.cordova.battery-status`
> >
> > * Add Tizen plugin support
> >
> > `org.apache.cordova.camera`
> > * CB-4919 firefox os quirks added and supported platforms list is updated
> > * getPicture via web activities
> > * Documented quirk for CB-5335 + CB-5206 for WP7+8
> > * reference the correct firefoxos implementation
> > * [BlackBerry10] Add permission to access_shared
> >
> > `org.apache.cordova.console`
> > * Native console needs to be called DebugConsole to avoid ambiguous
> > reference. This commit requires the 3.4.0 version of the native class
> > factory
> > * CB-4718 fixed Console plugin not working on wp
> >
> > `org.apache.cordova.contacts`
> > * [CB-3208] FFOS docs updated
> > * CB-4590 - chooseContact in CDVContacts crashes app
> >
> > `org.apache.cordova.device`
> >
> > * Tizen support added
> >
> > `org.apache.cordova.device-motion`
> >
> > * Add Tizen support
> >
> > `org.apache.cordova.device-orientation`
> > * [ubuntu] request sensors permission
> > * [ubuntu] add missing files
> > * Add support for Tizen.
> > * FFOS info added
> >
> > `org.apache.cordova.dialogs`
> > * no need to recreate the manifest.webapp file after each `cordova
> > prepare` for FFOS
> > * FFOS description added
> >
> > `org.apache.cordova.file`
> > * CB-5974: Use safe 'Compatibility' mode by default
> > * CB-5915: Add option for new persistent storage location for iOS
> > * CB-5916: Add option for new persistent storage location for Android
> > * Add default FS root to new FS objects
> > * CB-5899: Make DirectoryReader.readEntries return properly formatted
> > Entry objects
> > * Add constructor params to FileUploadResult related to CB-2421
> > * Fill out filesystem attribute of entities returned from
> > resolveLocalFileSystemURL
> > * Android: Expose filePlugin getter so that other plugins can register
> > filesystems
> > * Add backwards-compatibility shim for file-transfer
> > * Android: Allow third-party plugin registration
> > * CB-5810 [BlackBerry10] resolve local:/// paths (application assets)
> > * CB-5774: create DirectoryEn

Re: Plugins Release!

[Steven Gill]

ship it?


On Fri, Feb 7, 2014 at 12:03 PM, Steven Gill  wrote:

> Thanks for the feedback Ian! Just waiting on the "SHIP IT"
>
> Updated blog below:
>
> ---
> layout: post
> author:
> name: Steve Gill
> url: https://twitter.com/stevesgill
> title:  "Plugins Release: Feb 7, 2014"
> categories: news
> tags: release
> ---
> The following plugins were updated today:
>
> * org.apache.cordova.battery-status@0.2.7
> * org.apache.cordova.camera@0.2.7
> * org.apache.cordova.console@0.2.7
> * org.apache.cordova.contacts@0.2.8
> * org.apache.cordova.device@0.2.8
> * org.apache.cordova.device-motion@0.2.6
> * org.apache.cordova.device-orientation@0.3.5
> * org.apache.cordova.dialogs@0.2.6
> * org.apache.cordova.file@1.0.0
> * org.apache.cordova.file-transfer@0.4.1
> * org.apache.cordova.geolocation@0.3.6
> * org.apache.cordova.globalization@0.2.6
> * org.apache.cordova.inappbrowser@0.3.1
> * org.apache.cordova.media@0.2.8
> * org.apache.cordova.media-capture@0.2.7
> * org.apache.cordova.network-information@0.2.7
> * org.apache.cordova.vibration@0.3.7
>
> The most noticeable changes in this release are to the File plugin. It has
> been revamped to use a new URL scheme
> `cdvfile://localhost//`. These URLs are
> generated by all file operations, and are passed over the bridge to native
> code. (This is in contrast to the previous version, which passed around
> absolute paths on the device filesystem).
>
> Most of these changes are to bring us more in line with the HTML
> Filesystem standard, although they will also allow us to extend the
> filesystem abstraction to cover new kinds of storage, both internal and
> external to devices.
>
> Other changes include:
> 
> * The file plugin is now much more modular. The "Filesystem" is now an
> abstract class that developers can subclass to write their own filesystem
> types.
> * Developers can use the existing filesystem types, or new types, to
> provide new filesystem roots for their applications. (No longer limited to
> just persistent and temporary, or just a single directory for storage.)
> * Filesystem URLs paths are now relative to the filesystem root, helping
> to sandbox the filesystems and keep applications from stepping on each
> others' toes.
> * Application developers can now configure the file plugin to use a more
> sensible location for storing persistent files. On iOS, this means storing
> files in the Library directory, rather than the Documents directory. On
> Android, it means using the application's internal storage directory rather
> than the SD card partition. See the README file for information on
> configuring your applications.
> * Several other bugs have been fixed, and our test coverage has increased.
>
> `org.apache.cordova.battery-status`
>
> * Add Tizen plugin support
>
> `org.apache.cordova.camera`
> * CB-4919 firefox os quirks added and supported platforms list is updated
> * getPicture via web activities
> * Documented quirk for CB-5335 + CB-5206 for WP7+8
> * reference the correct firefoxos implementation
> * [BlackBerry10] Add permission to access_shared
>
> `org.apache.cordova.console`
> * Native console needs to be called DebugConsole to avoid ambiguous
> reference. This commit requires the 3.4.0 version of the native class
> factory
> * CB-4718 fixed Console plugin not working on wp
>
> `org.apache.cordova.contacts`
> * [CB-3208] FFOS docs updated
> * CB-4590 - chooseContact in CDVContacts crashes app
>
> `org.apache.cordova.device`
>
> * Tizen support added
>
> `org.apache.cordova.device-motion`
>
> * Add Tizen support
>
> `org.apache.cordova.device-orientation`
> * [ubuntu] request sensors permission
> * [ubuntu] add missing files
> * Add support for Tizen.
> * FFOS info added
>
> `org.apache.cordova.dialogs`
> * no need to recreate the manifest.webapp file after each `cordova
> prepare` for FFOS
> * FFOS description added
>
> `org.apache.cordova.file`
> * CB-5974: Use safe 'Compatibility' mode by default
> * CB-5915: Add option for new persistent storage location for iOS
> * CB-5916: Add option for new persistent storage location for Android
> * Add default FS root to new FS objects
> * CB-5899: Make DirectoryReader.readEntries return properly formatted
> Entry objects
> * Add constructor params to FileUploadResult related to CB-2421
> * Fill out filesystem attribute of entities returned from
> resolveLocalFileSystemURL
> * Android: Expose filePlugin getter so that other plugins can register
> filesystems
> * Add backwards-compatibility shim for file-transfer
> * Android: Allow third-party plugin registration
> * CB-5810 [BlackBerry10] resolve local:/// paths (application assets)
> * CB-5774: create DirectoryEntry instead of FileEntry
> * Initial fix for CB-5747: Windows 8: DirectoryEntry.getDirectory fails
> when path contains directory separator
> * Android: Allow absolute paths on Entry.getFile / Entry.getDirectory
> * CB-5008: Rename resolveLocalFileSystemURI to resolveLocalFileSystemURL
> * CB-4899 [BlackBerry10] Fix resolve

Re: Plugins Release!

[Steven Gill]

Thanks for the feedback Ian! Just waiting on the "SHIP IT"

Updated blog below:

---
layout: post
author:
name: Steve Gill
url: https://twitter.com/stevesgill
title:  "Plugins Release: Feb 7, 2014"
categories: news
tags: release
---
The following plugins were updated today:

* org.apache.cordova.battery-status@0.2.7
* org.apache.cordova.camera@0.2.7
* org.apache.cordova.console@0.2.7
* org.apache.cordova.contacts@0.2.8
* org.apache.cordova.device@0.2.8
* org.apache.cordova.device-motion@0.2.6
* org.apache.cordova.device-orientation@0.3.5
* org.apache.cordova.dialogs@0.2.6
* org.apache.cordova.file@1.0.0
* org.apache.cordova.file-transfer@0.4.1
* org.apache.cordova.geolocation@0.3.6
* org.apache.cordova.globalization@0.2.6
* org.apache.cordova.inappbrowser@0.3.1
* org.apache.cordova.media@0.2.8
* org.apache.cordova.media-capture@0.2.7
* org.apache.cordova.network-information@0.2.7
* org.apache.cordova.vibration@0.3.7

The most noticeable changes in this release are to the File plugin. It has
been revamped to use a new URL scheme
`cdvfile://localhost//`. These URLs are
generated by all file operations, and are passed over the bridge to native
code. (This is in contrast to the previous version, which passed around
absolute paths on the device filesystem).

Most of these changes are to bring us more in line with the HTML Filesystem
standard, although they will also allow us to extend the filesystem
abstraction to cover new kinds of storage, both internal and external to
devices.

Other changes include:

* The file plugin is now much more modular. The "Filesystem" is now an
abstract class that developers can subclass to write their own filesystem
types.
* Developers can use the existing filesystem types, or new types, to
provide new filesystem roots for their applications. (No longer limited to
just persistent and temporary, or just a single directory for storage.)
* Filesystem URLs paths are now relative to the filesystem root, helping to
sandbox the filesystems and keep applications from stepping on each others'
toes.
* Application developers can now configure the file plugin to use a more
sensible location for storing persistent files. On iOS, this means storing
files in the Library directory, rather than the Documents directory. On
Android, it means using the application's internal storage directory rather
than the SD card partition. See the README file for information on
configuring your applications.
* Several other bugs have been fixed, and our test coverage has increased.

`org.apache.cordova.battery-status`

* Add Tizen plugin support

`org.apache.cordova.camera`
* CB-4919 firefox os quirks added and supported platforms list is updated
* getPicture via web activities
* Documented quirk for CB-5335 + CB-5206 for WP7+8
* reference the correct firefoxos implementation
* [BlackBerry10] Add permission to access_shared

`org.apache.cordova.console`
* Native console needs to be called DebugConsole to avoid ambiguous
reference. This commit requires the 3.4.0 version of the native class
factory
* CB-4718 fixed Console plugin not working on wp

`org.apache.cordova.contacts`
* [CB-3208] FFOS docs updated
* CB-4590 - chooseContact in CDVContacts crashes app

`org.apache.cordova.device`

* Tizen support added

`org.apache.cordova.device-motion`

* Add Tizen support

`org.apache.cordova.device-orientation`
* [ubuntu] request sensors permission
* [ubuntu] add missing files
* Add support for Tizen.
* FFOS info added

`org.apache.cordova.dialogs`
* no need to recreate the manifest.webapp file after each `cordova prepare`
for FFOS
* FFOS description added

`org.apache.cordova.file`
* CB-5974: Use safe 'Compatibility' mode by default
* CB-5915: Add option for new persistent storage location for iOS
* CB-5916: Add option for new persistent storage location for Android
* Add default FS root to new FS objects
* CB-5899: Make DirectoryReader.readEntries return properly formatted Entry
objects
* Add constructor params to FileUploadResult related to CB-2421
* Fill out filesystem attribute of entities returned from
resolveLocalFileSystemURL
* Android: Expose filePlugin getter so that other plugins can register
filesystems
* Add backwards-compatibility shim for file-transfer
* Android: Allow third-party plugin registration
* CB-5810 [BlackBerry10] resolve local:/// paths (application assets)
* CB-5774: create DirectoryEntry instead of FileEntry
* Initial fix for CB-5747: Windows 8: DirectoryEntry.getDirectory fails
when path contains directory separator
* Android: Allow absolute paths on Entry.getFile / Entry.getDirectory
* CB-5008: Rename resolveLocalFileSystemURI to resolveLocalFileSystemURL
* CB-4899 [BlackBerry10] Fix resolve directories
* CB-5602 Windows8. Fix File Api mobile spec tests
* Android: Better support for content urls and cross-filesystem copy/move
ops
* CB-5699 [BlackBerry10] Update resolveLocalFileSystemURI implementation
* CB-5658 Update license comment formatting of doc/index.md
* CB-5658 Add doc.inde

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[Tommy Williams]

+1 for a warning..

"Warnings are the precursors to education" - me, just now
On 07/02/2014 11:55 am, "Marcel Kinard"  wrote:

> +1 to this.
>
> How about this addition: if the setting isn't explicitly declared in
> config.xml, log a warning but still default to exactly where they are now.
>
> On Feb 5, 2014, at 10:50 AM, Ian Clelland  wrote:
>
> > So this proposal would be:
> > - Don't revert the changes made on dev
> > - Don't rename the plugin
> > - Add a default which places files exactly where they are now
> > - Bump the major version
> > - Start fixing bugs in the new code. (without being distracted by the
> > storage location change)
> > - Start blogging about the issue with storage locations, and encourage
> > people to change (but don't force them to do anything yet)
> > - In a year, or when we feel that a sufficient mass of developers have
> > gotten the message, broadcast that we're removing the default. (or
> changing
> > it, if we're very confident in our plugin upgrade paths)
> > - Some months after that, make the change. (and hopefully not be
> > distracted by bugs in the underlying plugin code) Bump the major version
> > again.
>
>

Re: Plugins Release!

[Ian Clelland]

I've taken a first pass at the file plugin (I'll probably revisit it in the
morning and think it's terrible :) )

On Thu, Feb 6, 2014 at 4:44 PM, Steven Gill  wrote:

> Okay, I have a blog post ready to review. I could use some help with adding
> more content about the file plugin release. I got most of my info for it
> from http://markmail.org/thread/ebm3ms6of24rhyvb.
>
> I have also gone through the commits and removed ones I thought were
> unimportant. If you feel more curating needs to be done, feel free to edit.
>


The most noticeable changes in this release are to the File plugin. It has
been revamped to use a new URL scheme
`cdvfile://localhost//`. These URLs are
generated by all file operations, and are passed over the bridge to native
code. (This is in contrast to the previous version, which passed around
absolute paths on the device filesystem).

Most of these changes are to bring us more in line with the HTML Filesystem
standard, although they will also allow us to extend the filesystem
abstraction
 to cover new kinds of storage, both internal and external to devices.

Other changes include:
  * The file plugin is now much more modular. The "Filesystem" is now an
abstract class that developers can subclass to write their own
filesystem
types.
  * Developers can use the existing filesystem types, or new types, to
provide new filesystem roots for their applications. (No longer limited
to
just persistent and temporary, or just a single directory for storage.)
  * Filesystem URLs paths are now relative to the filesystem root, helping
to sandbox the filesystems and keep applications from stepping on
each others' toes.
  * Application developers can now configure the file plugin to use a more
sensible location for storing persistent files. On iOS, this means
storing
files in the Library directory, rather than the Documents directory. On
Android, it means using the application's internal storage directory
rather
than the SD card partition. See the README file for information on
configuring your applications.
  * Several other bugs have been fixed, and our test coverage has increased.


[Much curating of file changes; too many commits for the number of issues
fixed ;) ]


> `org.apache.cordova.file`
> * CB-5974: Use safe 'Compatibility' mode by default
> * CB-5915: Add option for new persistent storage location for iOS

* CB-5916: Add option for new persistent storage location for Android

> * Add default FS root to new FS objects
> * CB-5899: Make DirectoryReader.readEntries return properly formatted Entry
> objects
> * Add constructor params to FileUploadResult related to CB-2421
> * Fill out filesystem attribute of entities returned from
> resolveLocalFileSystemURL
> * Android: Expose filePlugin getter so that other plugins can register
> filesystems
> * Add backwards-compatibility shim for file-transfer
> * Android: Allow third-party plugin registration
> * CB-5810 [BlackBerry10] resolve local:/// paths (application assets)
> * CB-5774: create DirectoryEntry instead of FileEntry
> * Initial fix for CB-5747: Windows 8: DirectoryEntry.getDirectory fails
> when path contains directory separator
> * Android: Allow absolute paths on Entry.getFile / Entry.getDirectory
> * CB-5008: Rename resolveLocalFileSystemURI to resolveLocalFileSystemURL
> * CB-4899 [BlackBerry10] Fix resolve directories
> * CB-5602 Windows8. Fix File Api mobile spec tests
> * Android: Better support for content urls and cross-filesystem copy/move
> ops
> * CB-5699 [BlackBerry10] Update resolveLocalFileSystemURI implementation
> * CB-5658 Update license comment formatting of doc/index.md
> * CB-5658 Add doc.index.md for File plugin.
> * CB-5658 Delete stale snapshot of plugin docs
> * CB-5403: Backwards-compatibility with file:// urls where possible
> * Android: Clean up unclosed file objects
> * Log file path for File exceptions.
> * CB-5532 WP8. Add binary data support to FileWriter
> * CB-5531 WP8. File Api readAsText incorrectly handles position args
> * Added ubuntu platform support
> * Added amazon-fireos platform support
> * CB-5118 [BlackBerry10] Add check for undefined error handler
> * CB-5403: Bump File plugin major version
> * CB-5408: Add handler for filesystem urls
> * CB-5407: Update Android native code to use filesystem URLs internally
> * CB-5406: Update iOS native code to use filesystem URLs internally
> * CB-5405: Update JS code to use URLs exclusively
> * CB-4816 Fix file creation outside sandbox for BB10
>

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[Marcel Kinard]

+1 to this.

How about this addition: if the setting isn't explicitly declared in 
config.xml, log a warning but still default to exactly where they are now.

On Feb 5, 2014, at 10:50 AM, Ian Clelland  wrote:

> So this proposal would be:
> - Don't revert the changes made on dev
> - Don't rename the plugin
> - Add a default which places files exactly where they are now
> - Bump the major version
> - Start fixing bugs in the new code. (without being distracted by the
> storage location change)
> - Start blogging about the issue with storage locations, and encourage
> people to change (but don't force them to do anything yet)
> - In a year, or when we feel that a sufficient mass of developers have
> gotten the message, broadcast that we're removing the default. (or changing
> it, if we're very confident in our plugin upgrade paths)
> - Some months after that, make the change. (and hopefully not be
> distracted by bugs in the underlying plugin code) Bump the major version
> again.

Re: Plugins Release!

[Steven Gill]

 CB-5658 Add doc.index.md for File plugin.
* CB-5658 Delete stale snapshot of plugin docs
* CB-5403: Backwards-compatibility with file:// urls where possible
* CB-5407: Fixes for ContentFilesystem
* Android: Add method for testing backwards-compatibility of filetransfer
plugin
* iOS: Add method for testing backwards-compatiblity of filetransfer plugin
* Android: Updates to allow FileTransfer to continue to work
* Android: Clean up unclosed file objects
* CB-5407: Add new Android source files to plugin.xml
* CB-5407: Move read, write and truncate methods into modules
* CB-5407: Move copy/move methods into FS modules
* CB-5407: Move getParent into FS modules
* CB-5407: Move getmetadata methods into FS modules
* CB-5407: Move readdir methods into FS modules
* CB-5407: Move remove methods into FS modules
* CB-5407: Move getFile into FS modules
* CB-5407: Start refactoring android code: Modular filesystems, rfs, rlfsurl
* CB-5407: Update android JS to use FS urls
* CB-5405: Use URL formatting for Entry.toURL
* Log file path for File exceptions.
* Partial fix for iOS File compatibility with previous fileTransfer plugin
* CB-5532 WP8. Add binary data support to FileWriter
* CB-5531 WP8. File Api readAsText incorrectly handles position args
* Added ubuntu platform support
* Added amazon-fireos platform support
* CB-5118 [BlackBerry10] Add check for undefined error handler
* CB-5406: Extend public API for dependent plugins
* CB-5403: Bump File plugin major version
* CB-5406: Split iOS file plugin into modules
* CB-5406: Factor out filesystem providers in iOS
* CB-5408: Add handler for filesystem:// urls
* CB-5406: Update iOS native code to use filesystem URLs internally
* CB-5405: Update JS code to use URLs exclusively
* CB-4816 Fix file creation outside sandbox for BB10

`org.apache.cordova.file-transfer@0.4.1`
* CB-5365 Remove unused exception var to prevent warnings?
* CB-2421 explicitly write the bytesSent,responseCode,result to the
FileUploadResult pending release of cordova-plugin-file dependency, added
some sanity checks for callbacks
* iOS: Update for new file plugin api
* CB-5631 Removed SimpleTrackingInputStream.read(byte[] buffer)
* CB-5762 android: Fix lengthComputable set wrong for gzip downloads
* CB-4899 [BlackBerry10] Improve binary file transfer download
* CB-5722 [BlackBerry10] Update upload function to use native file object
* CB-5658 Delete stale snapshot of plugin docs
* CB-5466: Update to work with filesystem URLs

`org.apache.cordova.geolocation`
* add ubuntu platform support
* CB-5326 adding FFOS permission and updating supported platforms
* CB-5729 [BlackBerry10] Update GeolocationProxy to return collapsed object

`org.apache.cordova.globalization`
* Add Tizen plugin support

`org.apache.cordova.inappbrowser`
* CB-5756: Android: Use WebView.evaluateJavascript for script injection on
Android 4.4+
* Didn't test on ICS or lower, getDrawable isn't supported until Jellybean
* add ubuntu platform
* Adding drawables to the inAppBrowser.  This doesn't look quite right, but
it's a HUGE improvement over the previous settings
* CB-5756: Android: Use WebView.evaluateJavascript for script injection on
Android 4.4+
* Remove alive from InAppBrowser.js since it didn't catch the case where
the browser is closed by the user.
* CB-5733 Fix IAB.close() not working if called before show() animation is
done

`org.apache.cordova.media`
* Add preliminary support for Tizen.
* [CB-4755] Fix crash in Media.setVolume on iOS

`org.apache.cordova.media-capture`
* [ubuntu] request audio/camera/microphone permission
* fixed  cordova cli add capture plugin not work wp
* CB-5685 [BlackBerry10] Add access_shared permission

`org.apache.cordova.network-information`
* Initial implementation of Tizen plugin.

`org.apache.cordova.splashscreen`
* [CB-3562] Fix aspect ratio on landscape-only iPhone applications
* CB-4051 fix for splashscreen rotation problem

`org.apache.cordova.vibration`
* Add support for Tizen.
* CB-3206 - Supported platforms updated

The plugins have been updated on our registry at [plugins.cordova.io](
http://plugins.cordova.io/).

E.g. To update your vibration plugin:

cordova plugin rm org.apache.cordova.vibration
cordova plugin add org.apache.cordova.vibration








On Tue, Feb 4, 2014 at 3:20 PM, Joe Bowser  wrote:

> Don't do it!  I think File still needs some work:
>
> https://issues.apache.org/jira/browse/CB-5974
>
> On Tue, Feb 4, 2014 at 3:18 PM, Herm Wong 
> wrote:
> >
> >
> > Sounds good to me!
> >> From: agri...@chromium.org
> >> Date: Tue, 4 Feb 2014 14:35:01 -0500
> >> Subject: Re: Plugins Release!
> >> To: dev@cordova.apache.org
> >>
> >> Sounds good!
> >>
> >>
> >> On Tue, Feb 4, 2014 at 2:19 PM, Steven Gill 
> wrote:
> >>
> >> > I am going to take the silence as lazy consensus. I will make sure to
> &g

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[Anis KADRI]

It sounds like a good plan indeed. I would encourage our users to migrate
to the new locations as soon as they can. 12 months is an acceptable
migration window I believe.

+1 to Ian's proposal.


On Wed, Feb 5, 2014 at 1:43 PM, Jesse  wrote:

> +1 to Ian's proposal
>
> @purplecabbage
> risingj.com
>
>
> On Wed, Feb 5, 2014 at 1:33 PM, Andrew Grieve 
> wrote:
>
> > Joe - I appreciate your effort and your input, but I don't appreciate
> > hostility on this list from anyone, including you.
> > This is a public list, and I see nothing wrong with sebb's email in this
> > thread.
> > If you are at the point that you don't want to receive emails from sebb,
> > then I would ask that you choose to ignore them, or to create an email
> > filter on your end.
> >
> > +1 to Ian's proposal.
> >
> >
> > On Wed, Feb 5, 2014 at 11:01 AM, Joe Bowser  wrote:
> >
> > > Can you please leave this list sebb? You opinion is unwelcome!
> > >
> > > On Wed, Feb 5, 2014 at 6:05 AM, sebb  wrote:
> > > > On 5 February 2014 13:20, David Kemp  wrote:
> > > >> -1 to merging reads. That just sounds like a horrible thing to
> debug.
> > > >
> > > > Seems to me that developers using the plugin will have to implement
> > > > something similar in order to make it easier for their users.
> > > >
> > > > Would it not be better to spend the time getting it right once, for
> > > > the benfit of all developers, rather than hoping they each get it
> > > > right?
> > > >
> > > > I don't know what is involved here, so this is theoretical.
> > > > But I believe that compatibility should only be broken if necessary.
> > > > Also that fixing a problem at source is usually a lot cheaper than
> > > > requiring downstream developers/users to do so.
> > > > There are lots more of them, so any extra effort they have to expend
> > > > is multiplied many times.
> > > > In other words, the cost-benefit should not just look at the
> immediate
> > > > cost to the project.
> > > >
> > > >> +1 to 'go big or go home'. Break it now. Break it obviously.
> > > >
> > > > But I agree that breakage - if decided on - should be obvious.
> > > >
> > > >>
> > > >> On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref 
> > > wrote:
> > > >>
> > > >>> Is it impossible to have reads merged from both locations, but
> writes
> > > go
> > > >>> to the new location, and when a write completes in the new
> location,
> > > delete
> > > >>> the old one?
> > >
> >
>

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[Jesse]

+1 to Ian's proposal

@purplecabbage
risingj.com


On Wed, Feb 5, 2014 at 1:33 PM, Andrew Grieve  wrote:

> Joe - I appreciate your effort and your input, but I don't appreciate
> hostility on this list from anyone, including you.
> This is a public list, and I see nothing wrong with sebb's email in this
> thread.
> If you are at the point that you don't want to receive emails from sebb,
> then I would ask that you choose to ignore them, or to create an email
> filter on your end.
>
> +1 to Ian's proposal.
>
>
> On Wed, Feb 5, 2014 at 11:01 AM, Joe Bowser  wrote:
>
> > Can you please leave this list sebb? You opinion is unwelcome!
> >
> > On Wed, Feb 5, 2014 at 6:05 AM, sebb  wrote:
> > > On 5 February 2014 13:20, David Kemp  wrote:
> > >> -1 to merging reads. That just sounds like a horrible thing to debug.
> > >
> > > Seems to me that developers using the plugin will have to implement
> > > something similar in order to make it easier for their users.
> > >
> > > Would it not be better to spend the time getting it right once, for
> > > the benfit of all developers, rather than hoping they each get it
> > > right?
> > >
> > > I don't know what is involved here, so this is theoretical.
> > > But I believe that compatibility should only be broken if necessary.
> > > Also that fixing a problem at source is usually a lot cheaper than
> > > requiring downstream developers/users to do so.
> > > There are lots more of them, so any extra effort they have to expend
> > > is multiplied many times.
> > > In other words, the cost-benefit should not just look at the immediate
> > > cost to the project.
> > >
> > >> +1 to 'go big or go home'. Break it now. Break it obviously.
> > >
> > > But I agree that breakage - if decided on - should be obvious.
> > >
> > >>
> > >> On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref 
> > wrote:
> > >>
> > >>> Is it impossible to have reads merged from both locations, but writes
> > go
> > >>> to the new location, and when a write completes in the new location,
> > delete
> > >>> the old one?
> >
>

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[Andrew Grieve]

Joe - I appreciate your effort and your input, but I don't appreciate
hostility on this list from anyone, including you.
This is a public list, and I see nothing wrong with sebb's email in this
thread.
If you are at the point that you don't want to receive emails from sebb,
then I would ask that you choose to ignore them, or to create an email
filter on your end.

+1 to Ian's proposal.


On Wed, Feb 5, 2014 at 11:01 AM, Joe Bowser  wrote:

> Can you please leave this list sebb? You opinion is unwelcome!
>
> On Wed, Feb 5, 2014 at 6:05 AM, sebb  wrote:
> > On 5 February 2014 13:20, David Kemp  wrote:
> >> -1 to merging reads. That just sounds like a horrible thing to debug.
> >
> > Seems to me that developers using the plugin will have to implement
> > something similar in order to make it easier for their users.
> >
> > Would it not be better to spend the time getting it right once, for
> > the benfit of all developers, rather than hoping they each get it
> > right?
> >
> > I don't know what is involved here, so this is theoretical.
> > But I believe that compatibility should only be broken if necessary.
> > Also that fixing a problem at source is usually a lot cheaper than
> > requiring downstream developers/users to do so.
> > There are lots more of them, so any extra effort they have to expend
> > is multiplied many times.
> > In other words, the cost-benefit should not just look at the immediate
> > cost to the project.
> >
> >> +1 to 'go big or go home'. Break it now. Break it obviously.
> >
> > But I agree that breakage - if decided on - should be obvious.
> >
> >>
> >> On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref 
> wrote:
> >>
> >>> Is it impossible to have reads merged from both locations, but writes
> go
> >>> to the new location, and when a write completes in the new location,
> delete
> >>> the old one?
>

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[Ian Clelland]

I think this approach is our best path forward right now. There's no
immediate need to break apps for developers; it was a convenient time in
the development of the plugin, but we can easily wait for another
convenient time. There seems to be no compelling reason to couple a
breaking change with the other updates to the plugin.

I'm committing changes to the plugin now to support this; the actual "set
the default so things don't break" code is isolated to a single commit, so
that it's super easy to revert or change later if we decide we don't like
it.

I've asked around here, nobody on the Google team has any objections to
this path.

Anis, you were also agreeing with me previously about breaking sooner
rather than later: Are you okay now with separating the two issues, just
doing the API upgrade now, and starting the process of promoting the new
locations before we change the default sometime in the next 12 months?



On Wed, Feb 5, 2014 at 11:19 AM, Joe Bowser  wrote:

> Agreed! I didn't see that either until now.
>
> On Wed, Feb 5, 2014 at 8:04 AM, Tommy Williams  wrote:
> > Of course, while writing my rant, Ian has summarized a great proposal.
> >
> > +1 to the below!
> > On 06/02/2014 2:51 am, "Ian Clelland"  wrote:
> >
> >> On Wed, Feb 5, 2014 at 10:25 AM, Michal Mocny 
> wrote:
> >>
> >> > Honestly, my opinion on this: Leave the default as-is for now.  We've
> >> just
> >> > made huge changes to the API, which may have bugs / implications we
> >> haven't
> >> > fully thought through.
> >>
> >>
> >> That's a really good point. If we do this right now, we have two huge
> >> changes going on at the same time, and we will have to deal with a lot
> of
> >> heat for bugs *as well* as the location change.
> >>
> >>
> >> >  Lets let a subset of users upgrade to the new
> >> > $MAJOR version, and a subset of those add the new preference.  In a
> later
> >> > release, we can make the switch -- by then, maybe we will have more
> >> > solutions for migrating.
> >> >
> >> > Also, this is a nice to have, but its obviously been a situation that
> >> devs
> >> > have been living with for years.
> >> >
> >>
> >> That is something that I was thinking about last night. If we go with
> #3;
> >> put in a safe default, then we could spend a year if we wanted to
> promoting
> >> hard the "please please please switch to the better version" position.
> >>
> >> Then we could announce long in advance that we're changing the default,
> or
> >> that we're removing the default, and when we're ready, bump the major
> again
> >> to 2.x and do it.
> >>
> >> This might be the best situation for the developers, and it's no worse
> for
> >> the users than the situation right now. It's less than optimal for the
> >> "cordova ecosystem", but the ecosystem may be harmed more by angry
> >> developers leaving the platform than by continuing to place files where
> >> they are now.
> >>
> >>
> >> So this proposal would be:
> >>  - Don't revert the changes made on dev
> >>  - Don't rename the plugin
> >>  - Add a default which places files exactly where they are now
> >>  - Bump the major version
> >>  - Start fixing bugs in the new code. (without being distracted by the
> >> storage location change)
> >>  - Start blogging about the issue with storage locations, and encourage
> >> people to change (but don't force them to do anything yet)
> >>  - In a year, or when we feel that a sufficient mass of developers have
> >> gotten the message, broadcast that we're removing the default. (or
> changing
> >> it, if we're very confident in our plugin upgrade paths)
> >>  - Some months after that, make the change. (and hopefully not be
> >> distracted by bugs in the underlying plugin code) Bump the major version
> >> again.
> >>
> >> I'm actually pretty happy with that; we think that the current situation
> >> isn't great, but it doesn't seem to be actively hurting the ecosystem.
> And
> >> any developers who think otherwise will now have the tools to fix it for
> >> their own apps.
> >> Eventually we can be more opinionated about it, and the plugin will be
> more
> >> robust, so devs shouldn't be *as* angry as if we switched it right now.
> >>
> >> Ian
> >>
> >>
> >> > -Michal
> >> >
> >> >
> >> > On Wed, Feb 5, 2014 at 10:13 AM, sebb  wrote:
> >> >
> >> > > On 5 February 2014 14:55, David Kemp  wrote:
> >> > > > My concern with any automated fix is that we have no idea what
> files
> >> > > belong
> >> > > > to an app.
> >> > > > The default is to just toss everything in the root.
> >> > > > Files may be user data that is shared between apps, config files
> or
> >> > temp
> >> > > > files. The developer probably knows what to migrate - we don't.\
> >> > >
> >> > > The app must tell the library what file names are involved.
> >> > > So unless the same API is used for files that are supposed to remain
> >> > > in the root, it should be possible to know what needs to move.
> >> > >
> >> > > It  may still prove too difficult to implement the merge, but
>

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[Joe Bowser]

Agreed! I didn't see that either until now.

On Wed, Feb 5, 2014 at 8:04 AM, Tommy Williams  wrote:
> Of course, while writing my rant, Ian has summarized a great proposal.
>
> +1 to the below!
> On 06/02/2014 2:51 am, "Ian Clelland"  wrote:
>
>> On Wed, Feb 5, 2014 at 10:25 AM, Michal Mocny  wrote:
>>
>> > Honestly, my opinion on this: Leave the default as-is for now.  We've
>> just
>> > made huge changes to the API, which may have bugs / implications we
>> haven't
>> > fully thought through.
>>
>>
>> That's a really good point. If we do this right now, we have two huge
>> changes going on at the same time, and we will have to deal with a lot of
>> heat for bugs *as well* as the location change.
>>
>>
>> >  Lets let a subset of users upgrade to the new
>> > $MAJOR version, and a subset of those add the new preference.  In a later
>> > release, we can make the switch -- by then, maybe we will have more
>> > solutions for migrating.
>> >
>> > Also, this is a nice to have, but its obviously been a situation that
>> devs
>> > have been living with for years.
>> >
>>
>> That is something that I was thinking about last night. If we go with #3;
>> put in a safe default, then we could spend a year if we wanted to promoting
>> hard the "please please please switch to the better version" position.
>>
>> Then we could announce long in advance that we're changing the default, or
>> that we're removing the default, and when we're ready, bump the major again
>> to 2.x and do it.
>>
>> This might be the best situation for the developers, and it's no worse for
>> the users than the situation right now. It's less than optimal for the
>> "cordova ecosystem", but the ecosystem may be harmed more by angry
>> developers leaving the platform than by continuing to place files where
>> they are now.
>>
>>
>> So this proposal would be:
>>  - Don't revert the changes made on dev
>>  - Don't rename the plugin
>>  - Add a default which places files exactly where they are now
>>  - Bump the major version
>>  - Start fixing bugs in the new code. (without being distracted by the
>> storage location change)
>>  - Start blogging about the issue with storage locations, and encourage
>> people to change (but don't force them to do anything yet)
>>  - In a year, or when we feel that a sufficient mass of developers have
>> gotten the message, broadcast that we're removing the default. (or changing
>> it, if we're very confident in our plugin upgrade paths)
>>  - Some months after that, make the change. (and hopefully not be
>> distracted by bugs in the underlying plugin code) Bump the major version
>> again.
>>
>> I'm actually pretty happy with that; we think that the current situation
>> isn't great, but it doesn't seem to be actively hurting the ecosystem. And
>> any developers who think otherwise will now have the tools to fix it for
>> their own apps.
>> Eventually we can be more opinionated about it, and the plugin will be more
>> robust, so devs shouldn't be *as* angry as if we switched it right now.
>>
>> Ian
>>
>>
>> > -Michal
>> >
>> >
>> > On Wed, Feb 5, 2014 at 10:13 AM, sebb  wrote:
>> >
>> > > On 5 February 2014 14:55, David Kemp  wrote:
>> > > > My concern with any automated fix is that we have no idea what files
>> > > belong
>> > > > to an app.
>> > > > The default is to just toss everything in the root.
>> > > > Files may be user data that is shared between apps, config files or
>> > temp
>> > > > files. The developer probably knows what to migrate - we don't.\
>> > >
>> > > The app must tell the library what file names are involved.
>> > > So unless the same API is used for files that are supposed to remain
>> > > in the root, it should be possible to know what needs to move.
>> > >
>> > > It  may still prove too difficult to implement the merge, but perhaps
>> > > there is some scope for adding something to help the developers.
>> > >
>> > > For example, the code could check if there is a file with the same
>> > > name in the old location, and log a message if so.
>> > > There may be other checks that would help mitigate the breakage.
>> > >
>> > > >
>> > > > On Wed, Feb 5, 2014 at 9:05 AM, sebb  wrote:
>> > > >
>> > > >> On 5 February 2014 13:20, David Kemp  wrote:
>> > > >> > -1 to merging reads. That just sounds like a horrible thing to
>> > debug.
>> > > >>
>> > > >> Seems to me that developers using the plugin will have to implement
>> > > >> something similar in order to make it easier for their users.
>> > > >>
>> > > >> Would it not be better to spend the time getting it right once, for
>> > > >> the benfit of all developers, rather than hoping they each get it
>> > > >> right?
>> > > >>
>> > > >> I don't know what is involved here, so this is theoretical.
>> > > >> But I believe that compatibility should only be broken if necessary.
>> > > >> Also that fixing a problem at source is usually a lot cheaper than
>> > > >> requiring downstream developers/users to do so.
>> > > >> There are lots more of them, so any ext

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[Tommy Williams]

Of course, while writing my rant, Ian has summarized a great proposal.

+1 to the below!
On 06/02/2014 2:51 am, "Ian Clelland"  wrote:

> On Wed, Feb 5, 2014 at 10:25 AM, Michal Mocny  wrote:
>
> > Honestly, my opinion on this: Leave the default as-is for now.  We've
> just
> > made huge changes to the API, which may have bugs / implications we
> haven't
> > fully thought through.
>
>
> That's a really good point. If we do this right now, we have two huge
> changes going on at the same time, and we will have to deal with a lot of
> heat for bugs *as well* as the location change.
>
>
> >  Lets let a subset of users upgrade to the new
> > $MAJOR version, and a subset of those add the new preference.  In a later
> > release, we can make the switch -- by then, maybe we will have more
> > solutions for migrating.
> >
> > Also, this is a nice to have, but its obviously been a situation that
> devs
> > have been living with for years.
> >
>
> That is something that I was thinking about last night. If we go with #3;
> put in a safe default, then we could spend a year if we wanted to promoting
> hard the "please please please switch to the better version" position.
>
> Then we could announce long in advance that we're changing the default, or
> that we're removing the default, and when we're ready, bump the major again
> to 2.x and do it.
>
> This might be the best situation for the developers, and it's no worse for
> the users than the situation right now. It's less than optimal for the
> "cordova ecosystem", but the ecosystem may be harmed more by angry
> developers leaving the platform than by continuing to place files where
> they are now.
>
>
> So this proposal would be:
>  - Don't revert the changes made on dev
>  - Don't rename the plugin
>  - Add a default which places files exactly where they are now
>  - Bump the major version
>  - Start fixing bugs in the new code. (without being distracted by the
> storage location change)
>  - Start blogging about the issue with storage locations, and encourage
> people to change (but don't force them to do anything yet)
>  - In a year, or when we feel that a sufficient mass of developers have
> gotten the message, broadcast that we're removing the default. (or changing
> it, if we're very confident in our plugin upgrade paths)
>  - Some months after that, make the change. (and hopefully not be
> distracted by bugs in the underlying plugin code) Bump the major version
> again.
>
> I'm actually pretty happy with that; we think that the current situation
> isn't great, but it doesn't seem to be actively hurting the ecosystem. And
> any developers who think otherwise will now have the tools to fix it for
> their own apps.
> Eventually we can be more opinionated about it, and the plugin will be more
> robust, so devs shouldn't be *as* angry as if we switched it right now.
>
> Ian
>
>
> > -Michal
> >
> >
> > On Wed, Feb 5, 2014 at 10:13 AM, sebb  wrote:
> >
> > > On 5 February 2014 14:55, David Kemp  wrote:
> > > > My concern with any automated fix is that we have no idea what files
> > > belong
> > > > to an app.
> > > > The default is to just toss everything in the root.
> > > > Files may be user data that is shared between apps, config files or
> > temp
> > > > files. The developer probably knows what to migrate - we don't.\
> > >
> > > The app must tell the library what file names are involved.
> > > So unless the same API is used for files that are supposed to remain
> > > in the root, it should be possible to know what needs to move.
> > >
> > > It  may still prove too difficult to implement the merge, but perhaps
> > > there is some scope for adding something to help the developers.
> > >
> > > For example, the code could check if there is a file with the same
> > > name in the old location, and log a message if so.
> > > There may be other checks that would help mitigate the breakage.
> > >
> > > >
> > > > On Wed, Feb 5, 2014 at 9:05 AM, sebb  wrote:
> > > >
> > > >> On 5 February 2014 13:20, David Kemp  wrote:
> > > >> > -1 to merging reads. That just sounds like a horrible thing to
> > debug.
> > > >>
> > > >> Seems to me that developers using the plugin will have to implement
> > > >> something similar in order to make it easier for their users.
> > > >>
> > > >> Would it not be better to spend the time getting it right once, for
> > > >> the benfit of all developers, rather than hoping they each get it
> > > >> right?
> > > >>
> > > >> I don't know what is involved here, so this is theoretical.
> > > >> But I believe that compatibility should only be broken if necessary.
> > > >> Also that fixing a problem at source is usually a lot cheaper than
> > > >> requiring downstream developers/users to do so.
> > > >> There are lots more of them, so any extra effort they have to expend
> > > >> is multiplied many times.
> > > >> In other words, the cost-benefit should not just look at the
> immediate
> > > >> cost to the project.
> > > >>
> > > >> > +1 to 'go big or go 

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[Joe Bowser]

I couldn't have said it better myself. -1 to "just break it".


On Wed, Feb 5, 2014 at 8:00 AM, Tommy Williams  wrote:
> -1 to "just break it"
>
> Developers using Cordova still are frequently having to deal with massive
> breaking changes every few releases. Developing and (even more so)
> maintaining an app built using Cordova is actually pretty painful
> sometimes... Even for me, and I am on this list and see this stuff coming.
>
> If you think the new way is the best one true way, then leave the default
> as is and *educate* people as to why. The File API is one of the *most*
> used plugins of the core plugins. Breaking that big a percentage of
> existing apps  at 3.4 seems unwise to me.
>
> I know, I know... The plugins are separately versioned and this will be a
> major version change.. Tell me, has any dev had to know or really even been
> exposed to the fact that the plugins have their own versions yet? It's not
> like we have a package.json file with deps in it all semvered based on
> "last known good" versions like a node app might. I doubt many devs even
> know you *can* install a particular version of a plugin. If when installing
> a plugin we had --save-deps or something, and that used versions and kind
> of pinned the app to that major version, then a breaking version change
> might not break as many hearts ;)
>
> - tommy
> On 06/02/2014 2:26 am, "Michal Mocny"  wrote:
>
>> Honestly, my opinion on this: Leave the default as-is for now.  We've just
>> made huge changes to the API, which may have bugs / implications we haven't
>> fully thought through.  Lets let a subset of users upgrade to the new
>> $MAJOR version, and a subset of those add the new preference.  In a later
>> release, we can make the switch -- by then, maybe we will have more
>> solutions for migrating.
>>
>> Also, this is a nice to have, but its obviously been a situation that devs
>> have been living with for years.
>>
>> -Michal
>>
>>
>> On Wed, Feb 5, 2014 at 10:13 AM, sebb  wrote:
>>
>> > On 5 February 2014 14:55, David Kemp  wrote:
>> > > My concern with any automated fix is that we have no idea what files
>> > belong
>> > > to an app.
>> > > The default is to just toss everything in the root.
>> > > Files may be user data that is shared between apps, config files or
>> temp
>> > > files. The developer probably knows what to migrate - we don't.\
>> >
>> > The app must tell the library what file names are involved.
>> > So unless the same API is used for files that are supposed to remain
>> > in the root, it should be possible to know what needs to move.
>> >
>> > It  may still prove too difficult to implement the merge, but perhaps
>> > there is some scope for adding something to help the developers.
>> >
>> > For example, the code could check if there is a file with the same
>> > name in the old location, and log a message if so.
>> > There may be other checks that would help mitigate the breakage.
>> >
>> > >
>> > > On Wed, Feb 5, 2014 at 9:05 AM, sebb  wrote:
>> > >
>> > >> On 5 February 2014 13:20, David Kemp  wrote:
>> > >> > -1 to merging reads. That just sounds like a horrible thing to
>> debug.
>> > >>
>> > >> Seems to me that developers using the plugin will have to implement
>> > >> something similar in order to make it easier for their users.
>> > >>
>> > >> Would it not be better to spend the time getting it right once, for
>> > >> the benfit of all developers, rather than hoping they each get it
>> > >> right?
>> > >>
>> > >> I don't know what is involved here, so this is theoretical.
>> > >> But I believe that compatibility should only be broken if necessary.
>> > >> Also that fixing a problem at source is usually a lot cheaper than
>> > >> requiring downstream developers/users to do so.
>> > >> There are lots more of them, so any extra effort they have to expend
>> > >> is multiplied many times.
>> > >> In other words, the cost-benefit should not just look at the immediate
>> > >> cost to the project.
>> > >>
>> > >> > +1 to 'go big or go home'. Break it now. Break it obviously.
>> > >>
>> > >> But I agree that breakage - if decided on - should be obvious.
>> > >>
>> > >> >
>> > >> > On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref 
>> > >> wrote:
>> > >> >
>> > >> >> Is it impossible to have reads merged from both locations, but
>> > writes go
>> > >> >> to the new location, and when a write completes in the new
>> location,
>> > >> delete
>> > >> >> the old one?
>> > >>
>> >
>>

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[Joe Bowser]

Can you please leave this list sebb? You opinion is unwelcome!

On Wed, Feb 5, 2014 at 6:05 AM, sebb  wrote:
> On 5 February 2014 13:20, David Kemp  wrote:
>> -1 to merging reads. That just sounds like a horrible thing to debug.
>
> Seems to me that developers using the plugin will have to implement
> something similar in order to make it easier for their users.
>
> Would it not be better to spend the time getting it right once, for
> the benfit of all developers, rather than hoping they each get it
> right?
>
> I don't know what is involved here, so this is theoretical.
> But I believe that compatibility should only be broken if necessary.
> Also that fixing a problem at source is usually a lot cheaper than
> requiring downstream developers/users to do so.
> There are lots more of them, so any extra effort they have to expend
> is multiplied many times.
> In other words, the cost-benefit should not just look at the immediate
> cost to the project.
>
>> +1 to 'go big or go home'. Break it now. Break it obviously.
>
> But I agree that breakage - if decided on - should be obvious.
>
>>
>> On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref  wrote:
>>
>>> Is it impossible to have reads merged from both locations, but writes go
>>> to the new location, and when a write completes in the new location, delete
>>> the old one?

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[Tommy Williams]

-1 to "just break it"

Developers using Cordova still are frequently having to deal with massive
breaking changes every few releases. Developing and (even more so)
maintaining an app built using Cordova is actually pretty painful
sometimes... Even for me, and I am on this list and see this stuff coming.

If you think the new way is the best one true way, then leave the default
as is and *educate* people as to why. The File API is one of the *most*
used plugins of the core plugins. Breaking that big a percentage of
existing apps  at 3.4 seems unwise to me.

I know, I know... The plugins are separately versioned and this will be a
major version change.. Tell me, has any dev had to know or really even been
exposed to the fact that the plugins have their own versions yet? It's not
like we have a package.json file with deps in it all semvered based on
"last known good" versions like a node app might. I doubt many devs even
know you *can* install a particular version of a plugin. If when installing
a plugin we had --save-deps or something, and that used versions and kind
of pinned the app to that major version, then a breaking version change
might not break as many hearts ;)

- tommy
On 06/02/2014 2:26 am, "Michal Mocny"  wrote:

> Honestly, my opinion on this: Leave the default as-is for now.  We've just
> made huge changes to the API, which may have bugs / implications we haven't
> fully thought through.  Lets let a subset of users upgrade to the new
> $MAJOR version, and a subset of those add the new preference.  In a later
> release, we can make the switch -- by then, maybe we will have more
> solutions for migrating.
>
> Also, this is a nice to have, but its obviously been a situation that devs
> have been living with for years.
>
> -Michal
>
>
> On Wed, Feb 5, 2014 at 10:13 AM, sebb  wrote:
>
> > On 5 February 2014 14:55, David Kemp  wrote:
> > > My concern with any automated fix is that we have no idea what files
> > belong
> > > to an app.
> > > The default is to just toss everything in the root.
> > > Files may be user data that is shared between apps, config files or
> temp
> > > files. The developer probably knows what to migrate - we don't.\
> >
> > The app must tell the library what file names are involved.
> > So unless the same API is used for files that are supposed to remain
> > in the root, it should be possible to know what needs to move.
> >
> > It  may still prove too difficult to implement the merge, but perhaps
> > there is some scope for adding something to help the developers.
> >
> > For example, the code could check if there is a file with the same
> > name in the old location, and log a message if so.
> > There may be other checks that would help mitigate the breakage.
> >
> > >
> > > On Wed, Feb 5, 2014 at 9:05 AM, sebb  wrote:
> > >
> > >> On 5 February 2014 13:20, David Kemp  wrote:
> > >> > -1 to merging reads. That just sounds like a horrible thing to
> debug.
> > >>
> > >> Seems to me that developers using the plugin will have to implement
> > >> something similar in order to make it easier for their users.
> > >>
> > >> Would it not be better to spend the time getting it right once, for
> > >> the benfit of all developers, rather than hoping they each get it
> > >> right?
> > >>
> > >> I don't know what is involved here, so this is theoretical.
> > >> But I believe that compatibility should only be broken if necessary.
> > >> Also that fixing a problem at source is usually a lot cheaper than
> > >> requiring downstream developers/users to do so.
> > >> There are lots more of them, so any extra effort they have to expend
> > >> is multiplied many times.
> > >> In other words, the cost-benefit should not just look at the immediate
> > >> cost to the project.
> > >>
> > >> > +1 to 'go big or go home'. Break it now. Break it obviously.
> > >>
> > >> But I agree that breakage - if decided on - should be obvious.
> > >>
> > >> >
> > >> > On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref 
> > >> wrote:
> > >> >
> > >> >> Is it impossible to have reads merged from both locations, but
> > writes go
> > >> >> to the new location, and when a write completes in the new
> location,
> > >> delete
> > >> >> the old one?
> > >>
> >
>

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[Ian Clelland]

On Wed, Feb 5, 2014 at 10:25 AM, Michal Mocny  wrote:

> Honestly, my opinion on this: Leave the default as-is for now.  We've just
> made huge changes to the API, which may have bugs / implications we haven't
> fully thought through.


That's a really good point. If we do this right now, we have two huge
changes going on at the same time, and we will have to deal with a lot of
heat for bugs *as well* as the location change.


>  Lets let a subset of users upgrade to the new
> $MAJOR version, and a subset of those add the new preference.  In a later
> release, we can make the switch -- by then, maybe we will have more
> solutions for migrating.
>
> Also, this is a nice to have, but its obviously been a situation that devs
> have been living with for years.
>

That is something that I was thinking about last night. If we go with #3;
put in a safe default, then we could spend a year if we wanted to promoting
hard the "please please please switch to the better version" position.

Then we could announce long in advance that we're changing the default, or
that we're removing the default, and when we're ready, bump the major again
to 2.x and do it.

This might be the best situation for the developers, and it's no worse for
the users than the situation right now. It's less than optimal for the
"cordova ecosystem", but the ecosystem may be harmed more by angry
developers leaving the platform than by continuing to place files where
they are now.


So this proposal would be:
 - Don't revert the changes made on dev
 - Don't rename the plugin
 - Add a default which places files exactly where they are now
 - Bump the major version
 - Start fixing bugs in the new code. (without being distracted by the
storage location change)
 - Start blogging about the issue with storage locations, and encourage
people to change (but don't force them to do anything yet)
 - In a year, or when we feel that a sufficient mass of developers have
gotten the message, broadcast that we're removing the default. (or changing
it, if we're very confident in our plugin upgrade paths)
 - Some months after that, make the change. (and hopefully not be
distracted by bugs in the underlying plugin code) Bump the major version
again.

I'm actually pretty happy with that; we think that the current situation
isn't great, but it doesn't seem to be actively hurting the ecosystem. And
any developers who think otherwise will now have the tools to fix it for
their own apps.
Eventually we can be more opinionated about it, and the plugin will be more
robust, so devs shouldn't be *as* angry as if we switched it right now.

Ian


> -Michal
>
>
> On Wed, Feb 5, 2014 at 10:13 AM, sebb  wrote:
>
> > On 5 February 2014 14:55, David Kemp  wrote:
> > > My concern with any automated fix is that we have no idea what files
> > belong
> > > to an app.
> > > The default is to just toss everything in the root.
> > > Files may be user data that is shared between apps, config files or
> temp
> > > files. The developer probably knows what to migrate - we don't.\
> >
> > The app must tell the library what file names are involved.
> > So unless the same API is used for files that are supposed to remain
> > in the root, it should be possible to know what needs to move.
> >
> > It  may still prove too difficult to implement the merge, but perhaps
> > there is some scope for adding something to help the developers.
> >
> > For example, the code could check if there is a file with the same
> > name in the old location, and log a message if so.
> > There may be other checks that would help mitigate the breakage.
> >
> > >
> > > On Wed, Feb 5, 2014 at 9:05 AM, sebb  wrote:
> > >
> > >> On 5 February 2014 13:20, David Kemp  wrote:
> > >> > -1 to merging reads. That just sounds like a horrible thing to
> debug.
> > >>
> > >> Seems to me that developers using the plugin will have to implement
> > >> something similar in order to make it easier for their users.
> > >>
> > >> Would it not be better to spend the time getting it right once, for
> > >> the benfit of all developers, rather than hoping they each get it
> > >> right?
> > >>
> > >> I don't know what is involved here, so this is theoretical.
> > >> But I believe that compatibility should only be broken if necessary.
> > >> Also that fixing a problem at source is usually a lot cheaper than
> > >> requiring downstream developers/users to do so.
> > >> There are lots more of them, so any extra effort they have to expend
> > >> is multiplied many times.
> > >> In other words, the cost-benefit should not just look at the immediate
> > >> cost to the project.
> > >>
> > >> > +1 to 'go big or go home'. Break it now. Break it obviously.
> > >>
> > >> But I agree that breakage - if decided on - should be obvious.
> > >>
> > >> >
> > >> > On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref 
> > >> wrote:
> > >> >
> > >> >> Is it impossible to have reads merged from both locations, but
> > writes go
> > >> >> to the new location, and when a write comple

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[Ian Clelland]

On Wed, Feb 5, 2014 at 10:29 AM, Anis KADRI  wrote:

> I also think we should break it now. It's not as if we have never broken
> anything before... keeping backward compatibility should anyways be
> preferred but in this case I think it would cause more trouble than it
> would solve.
> I say don't write any migration tools but document the changes in
> plugin.xml ( tag), write a blog post about it, tweet it, Google plus
> it and... Be super loud about it.
>
> It's not like we are breaking everything for everyone either. We have
> plugin versions for a reason.
>

Right, this was going to be the first test of a major version bump of a
published plugin. We want this to be a step that developers need to take
deliberately, I think.


>
> Another way of avoiding this would have been to pick a different name for
> this plugin. Is it too late?
>

Not too late; it would be some work to cherry-pick the unrelated fixes from
dev, but we could do it. Maybe we should do that anyway, and maintain an
0.x line for people who won't/cant' upgrade.

Ian

On Feb 5, 2014 7:03 AM, "Ian Clelland"  wrote:
>
> > On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref 
> wrote:
> >
> > > Is it impossible to have reads merged from both locations, but writes
> go
> > > to the new location, and when a write completes in the new location,
> > delete
> > > the old one?
> >
> >
> > It might be. The File API doesn't impose any sort of model for read/write
> > patterns. Reads and writes can happen anywhere in a file; we can't
> enforce
> > that a file is written out entirely in one call, so there may not be a
> > point where we can say "it's done; delete the old one".
> >
> > It's also entirely possible for multiple readers to be open on the file,
> > and for another thread to have a writer open, writing somewhere in the
> > middle of the file, so I would expect race conditions.
> >
> > This isn't *impossible*; there have been OS filesystems which do this
> for a
> > long time, but it seems to me to be a lot more work than writing a tool
> for
> > developers to use for migration, and much more error prone.
> >
>

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[Anis KADRI]

I also think we should break it now. It's not as if we have never broken
anything before... keeping backward compatibility should anyways be
preferred but in this case I think it would cause more trouble than it
would solve.
I say don't write any migration tools but document the changes in
plugin.xml ( tag), write a blog post about it, tweet it, Google plus
it and... Be super loud about it.

It's not like we are breaking everything for everyone either. We have
plugin versions for a reason.

Another way of avoiding this would have been to pick a different name for
this plugin. Is it too late?
On Feb 5, 2014 7:03 AM, "Ian Clelland"  wrote:

> On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref  wrote:
>
> > Is it impossible to have reads merged from both locations, but writes go
> > to the new location, and when a write completes in the new location,
> delete
> > the old one?
>
>
> It might be. The File API doesn't impose any sort of model for read/write
> patterns. Reads and writes can happen anywhere in a file; we can't enforce
> that a file is written out entirely in one call, so there may not be a
> point where we can say "it's done; delete the old one".
>
> It's also entirely possible for multiple readers to be open on the file,
> and for another thread to have a writer open, writing somewhere in the
> middle of the file, so I would expect race conditions.
>
> This isn't *impossible*; there have been OS filesystems which do this for a
> long time, but it seems to me to be a lot more work than writing a tool for
> developers to use for migration, and much more error prone.
>

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[Michal Mocny]

Honestly, my opinion on this: Leave the default as-is for now.  We've just
made huge changes to the API, which may have bugs / implications we haven't
fully thought through.  Lets let a subset of users upgrade to the new
$MAJOR version, and a subset of those add the new preference.  In a later
release, we can make the switch -- by then, maybe we will have more
solutions for migrating.

Also, this is a nice to have, but its obviously been a situation that devs
have been living with for years.

-Michal


On Wed, Feb 5, 2014 at 10:13 AM, sebb  wrote:

> On 5 February 2014 14:55, David Kemp  wrote:
> > My concern with any automated fix is that we have no idea what files
> belong
> > to an app.
> > The default is to just toss everything in the root.
> > Files may be user data that is shared between apps, config files or temp
> > files. The developer probably knows what to migrate - we don't.\
>
> The app must tell the library what file names are involved.
> So unless the same API is used for files that are supposed to remain
> in the root, it should be possible to know what needs to move.
>
> It  may still prove too difficult to implement the merge, but perhaps
> there is some scope for adding something to help the developers.
>
> For example, the code could check if there is a file with the same
> name in the old location, and log a message if so.
> There may be other checks that would help mitigate the breakage.
>
> >
> > On Wed, Feb 5, 2014 at 9:05 AM, sebb  wrote:
> >
> >> On 5 February 2014 13:20, David Kemp  wrote:
> >> > -1 to merging reads. That just sounds like a horrible thing to debug.
> >>
> >> Seems to me that developers using the plugin will have to implement
> >> something similar in order to make it easier for their users.
> >>
> >> Would it not be better to spend the time getting it right once, for
> >> the benfit of all developers, rather than hoping they each get it
> >> right?
> >>
> >> I don't know what is involved here, so this is theoretical.
> >> But I believe that compatibility should only be broken if necessary.
> >> Also that fixing a problem at source is usually a lot cheaper than
> >> requiring downstream developers/users to do so.
> >> There are lots more of them, so any extra effort they have to expend
> >> is multiplied many times.
> >> In other words, the cost-benefit should not just look at the immediate
> >> cost to the project.
> >>
> >> > +1 to 'go big or go home'. Break it now. Break it obviously.
> >>
> >> But I agree that breakage - if decided on - should be obvious.
> >>
> >> >
> >> > On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref 
> >> wrote:
> >> >
> >> >> Is it impossible to have reads merged from both locations, but
> writes go
> >> >> to the new location, and when a write completes in the new location,
> >> delete
> >> >> the old one?
> >>
>

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[Josh Soref]

Imagine a hypothetical implementation which works like this:

Consumer asks for a file, we don't find it in Library, nor is the "we're 
migrating file", we create the "we're migrating file", it's present in ‎Root. 
We start a copy in the background and return some file handle (probably a 
proxy). Any writes are written to the "we're migrating file" if that part of 
the file exists in addition to the original. When the copy completes, we rename 
"we're migrating" to the correct file. Then we delete the original. ‎
‎
Ian wrote:
> It might be.
> The File API doesn't impose any sort of model for read/write patterns.
> Reads and writes can happen anywhere in a file;
> we can't enforce that a file is written out entirely in one call,
> so there may not be a point where we can say "it's done; delete the old one".

> It's also entirely possible for multiple readers to be open on the file,
> and for another thread to have a writer open,
> writing somewhere in the middle of the file,
> so I would expect race conditions.

> This isn't *impossible*;
> there have been OS filesystems which do this for a long time,
> but it seems to me to be a lot more work than writing a tool for developers 
> to use for migration,
> and much more error prone.

Perhaps we should start with that. Shouldn't someone write a tool which scans 
for consumers and offers a survey and let's the developer pick an answer with 
which it rewrites the file? 

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[sebb]

On 5 February 2014 14:55, David Kemp  wrote:
> My concern with any automated fix is that we have no idea what files belong
> to an app.
> The default is to just toss everything in the root.
> Files may be user data that is shared between apps, config files or temp
> files. The developer probably knows what to migrate - we don't.\

The app must tell the library what file names are involved.
So unless the same API is used for files that are supposed to remain
in the root, it should be possible to know what needs to move.

It  may still prove too difficult to implement the merge, but perhaps
there is some scope for adding something to help the developers.

For example, the code could check if there is a file with the same
name in the old location, and log a message if so.
There may be other checks that would help mitigate the breakage.

>
> On Wed, Feb 5, 2014 at 9:05 AM, sebb  wrote:
>
>> On 5 February 2014 13:20, David Kemp  wrote:
>> > -1 to merging reads. That just sounds like a horrible thing to debug.
>>
>> Seems to me that developers using the plugin will have to implement
>> something similar in order to make it easier for their users.
>>
>> Would it not be better to spend the time getting it right once, for
>> the benfit of all developers, rather than hoping they each get it
>> right?
>>
>> I don't know what is involved here, so this is theoretical.
>> But I believe that compatibility should only be broken if necessary.
>> Also that fixing a problem at source is usually a lot cheaper than
>> requiring downstream developers/users to do so.
>> There are lots more of them, so any extra effort they have to expend
>> is multiplied many times.
>> In other words, the cost-benefit should not just look at the immediate
>> cost to the project.
>>
>> > +1 to 'go big or go home'. Break it now. Break it obviously.
>>
>> But I agree that breakage - if decided on - should be obvious.
>>
>> >
>> > On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref 
>> wrote:
>> >
>> >> Is it impossible to have reads merged from both locations, but writes go
>> >> to the new location, and when a write completes in the new location,
>> delete
>> >> the old one?
>>

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[Ian Clelland]

On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref  wrote:

> Is it impossible to have reads merged from both locations, but writes go
> to the new location, and when a write completes in the new location, delete
> the old one?


It might be. The File API doesn't impose any sort of model for read/write
patterns. Reads and writes can happen anywhere in a file; we can't enforce
that a file is written out entirely in one call, so there may not be a
point where we can say "it's done; delete the old one".

It's also entirely possible for multiple readers to be open on the file,
and for another thread to have a writer open, writing somewhere in the
middle of the file, so I would expect race conditions.

This isn't *impossible*; there have been OS filesystems which do this for a
long time, but it seems to me to be a lot more work than writing a tool for
developers to use for migration, and much more error prone.

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[David Kemp]

My concern with any automated fix is that we have no idea what files belong
to an app.
The default is to just toss everything in the root.
Files may be user data that is shared between apps, config files or temp
files. The developer probably knows what to migrate - we don't.\


On Wed, Feb 5, 2014 at 9:05 AM, sebb  wrote:

> On 5 February 2014 13:20, David Kemp  wrote:
> > -1 to merging reads. That just sounds like a horrible thing to debug.
>
> Seems to me that developers using the plugin will have to implement
> something similar in order to make it easier for their users.
>
> Would it not be better to spend the time getting it right once, for
> the benfit of all developers, rather than hoping they each get it
> right?
>
> I don't know what is involved here, so this is theoretical.
> But I believe that compatibility should only be broken if necessary.
> Also that fixing a problem at source is usually a lot cheaper than
> requiring downstream developers/users to do so.
> There are lots more of them, so any extra effort they have to expend
> is multiplied many times.
> In other words, the cost-benefit should not just look at the immediate
> cost to the project.
>
> > +1 to 'go big or go home'. Break it now. Break it obviously.
>
> But I agree that breakage - if decided on - should be obvious.
>
> >
> > On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref 
> wrote:
> >
> >> Is it impossible to have reads merged from both locations, but writes go
> >> to the new location, and when a write completes in the new location,
> delete
> >> the old one?
>

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[sebb]

On 5 February 2014 13:20, David Kemp  wrote:
> -1 to merging reads. That just sounds like a horrible thing to debug.

Seems to me that developers using the plugin will have to implement
something similar in order to make it easier for their users.

Would it not be better to spend the time getting it right once, for
the benfit of all developers, rather than hoping they each get it
right?

I don't know what is involved here, so this is theoretical.
But I believe that compatibility should only be broken if necessary.
Also that fixing a problem at source is usually a lot cheaper than
requiring downstream developers/users to do so.
There are lots more of them, so any extra effort they have to expend
is multiplied many times.
In other words, the cost-benefit should not just look at the immediate
cost to the project.

> +1 to 'go big or go home'. Break it now. Break it obviously.

But I agree that breakage - if decided on - should be obvious.

>
> On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref  wrote:
>
>> Is it impossible to have reads merged from both locations, but writes go
>> to the new location, and when a write completes in the new location, delete
>> the old one?

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[David Kemp]

-1 to merging reads. That just sounds like a horrible thing to debug.
+1 to 'go big or go home'. Break it now. Break it obviously.


On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref  wrote:

> Is it impossible to have reads merged from both locations, but writes go
> to the new location, and when a write completes in the new location, delete
> the old one?

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[Josh Soref]

Is it impossible to have reads merged from both locations, but writes go to the 
new location, and when a write completes in the new location, delete the old 
one? 

CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[Ian Clelland]

On Tue, Feb 4, 2014 at 6:20 PM, Joe Bowser  wrote:

> Don't do it!  I think File still needs some work:
>
> https://issues.apache.org/jira/browse/CB-5974


It's too early yet to tell whether this has become a problem, but obviously
this is something that people are going to run into (and are already
running into [1])

Background:

Because of CB-5915 [2] (and it's android sister, CB-5916 [3]), developers
who upgrade File will find that their applications crash with a log message
the first time they use any of the File API. (I'd crash sooner, but File is
not currently a load-on-startup sort of plugin)

There was a lot of discussion about this on the list [4], and I thought
that we had reached consensus, but maybe it needs one more hard look.

The Problem:

The log message hopefully tells them what they need to do to fix the
problem, but many (most?) devs aren't going to see it; they're only going
to see that their app is broken now, and come to us (hopefully) or
StackOverflow (more likely) to figure out why and what to do about it. They
will probably be loud, we will probably be blamed for their apps breaking
(no matter how simple the fix is,) and it will probably be a bad time for
everybody.

It's unfortunate that we feel we have to do this; there just doesn't seem
to be any other way to encourage developers to use anything but the old
locations for persistent files. On Android this is the
root-of-the-sdcard-even-if-its-just-a-partition-shared-by-all-apps
location. On iOS, its the Documents directory, although Library makes far
more sense for these sort of files.

If we added a default value, the only possible default we could use is
"Compatibility", which means that approximately 100% of new apps will ship
with that default. We *can't* use the new location as the default, because
that will cause real pain for the users, not the devs. Real users will lose
access to real data, and that worries me much more than a mob of angry devs
with pitchforks.


Options:

1. Go big or go home: Make it crash harder. I was already going to add a
paragraph to the plugin.xml file to be shown on install, but we *could*
make the app break on launch, rather than on the first use of File.
We could force File to load on startup, or we could make Javascript alert()
the dev on startup (something like "please fix config.xml and then delete
this line"), or we could break the plugin encapsulation and make
ConfigParser check for this special case.
Maybe we could go even further and find a way to make it break on build. At
least then apps wouldn't make it to the store broken.

2. Leave it the way it is. Brace for the angry mob with blog posts, release
notes, install guides, READMEs, vigilance on StackOverfow, and hope that
it's enough.

3. Put in the safe default and live with it. Accept that every single
Cordova app is going to use the default and that their file storage roots
will suck. By the time you've educated a developer, chances are their apps
have already been released and have users with stored data. Work hard on a
migration utility/plugin and make sure that it can never possibly lose data.

With my Google hat[5] on, I don't mind #3 -- we've ensured that the apps
created with our framework use the new defaults, since they're all new apps
by definition. Wearing my Apache hat, though, I don't think it's best for
Cordova in the long term. At some point, I think we should rip off the
bandaid. If we don't do it now, with a major rev bump of File, then we're
just postponing the hurt.

There may be other options; lets try to get consensus on this before
pulling the trigger.


[1] https://issues.apache.org/jira/browse/CB-5899
[2] https://issues.apache.org/jira/browse/CB-5915
[3] https://issues.apache.org/jira/browse/CB-5916
[4] http://markmail.org/message/tzcljj3xgycbkx3g
[5] http://www.flickr.com/photos/nooks/6858535568/

>
>
> On Tue, Feb 4, 2014 at 3:18 PM, Herm Wong 
> wrote:
> >
> >
> > Sounds good to me!
> >> From: agri...@chromium.org
> >> Date: Tue, 4 Feb 2014 14:35:01 -0500
> >> Subject: Re: Plugins Release!
> >> To: dev@cordova.apache.org
> >>
> >> Sounds good!
> >>
> >>
> >> On Tue, Feb 4, 2014 at 2:19 PM, Steven Gill 
> wrote:
> >>
> >> > I am going to take the silence as lazy consensus. I will make sure to
> >> > include the new file plugin as well.
> >> >
> >> > I will make sure to have a blog post of changes to review before I
> publish.
> >> >
> >> > -Steve
> >> >
> >> >
> >> >
> >> > On Mon, Feb 3, 2014 at 10:33 AM, Steven Gill 
> >> > wrote:
> >> >
> >> > > Hey All,
> >> > >
> >> > > What is the general feeling on me moving forward with a plugins
> release
> >> > > today? I could start the process this afternoon if there aren't any
> >> > > objections or concerns.
> >> > >
> >> > > Are there any plugins that shouldn't be released?
> >> > >
> >> >
> >
>

Re: Plugins Release!

[Joe Bowser]

Don't do it!  I think File still needs some work:

https://issues.apache.org/jira/browse/CB-5974

On Tue, Feb 4, 2014 at 3:18 PM, Herm Wong  wrote:
>
>
> Sounds good to me!
>> From: agri...@chromium.org
>> Date: Tue, 4 Feb 2014 14:35:01 -0500
>> Subject: Re: Plugins Release!
>> To: dev@cordova.apache.org
>>
>> Sounds good!
>>
>>
>> On Tue, Feb 4, 2014 at 2:19 PM, Steven Gill  wrote:
>>
>> > I am going to take the silence as lazy consensus. I will make sure to
>> > include the new file plugin as well.
>> >
>> > I will make sure to have a blog post of changes to review before I publish.
>> >
>> > -Steve
>> >
>> >
>> >
>> > On Mon, Feb 3, 2014 at 10:33 AM, Steven Gill 
>> > wrote:
>> >
>> > > Hey All,
>> > >
>> > > What is the general feeling on me moving forward with a plugins release
>> > > today? I could start the process this afternoon if there aren't any
>> > > objections or concerns.
>> > >
>> > > Are there any plugins that shouldn't be released?
>> > >
>> >
>

RE: Plugins Release!

[Herm Wong]

Sounds good to me!
> From: agri...@chromium.org
> Date: Tue, 4 Feb 2014 14:35:01 -0500
> Subject: Re: Plugins Release!
> To: dev@cordova.apache.org
> 
> Sounds good!
> 
> 
> On Tue, Feb 4, 2014 at 2:19 PM, Steven Gill  wrote:
> 
> > I am going to take the silence as lazy consensus. I will make sure to
> > include the new file plugin as well.
> >
> > I will make sure to have a blog post of changes to review before I publish.
> >
> > -Steve
> >
> >
> >
> > On Mon, Feb 3, 2014 at 10:33 AM, Steven Gill 
> > wrote:
> >
> > > Hey All,
> > >
> > > What is the general feeling on me moving forward with a plugins release
> > > today? I could start the process this afternoon if there aren't any
> > > objections or concerns.
> > >
> > > Are there any plugins that shouldn't be released?
> > >
> >
  

Re: Plugins Release!

[Andrew Grieve]

Sounds good!


On Tue, Feb 4, 2014 at 2:19 PM, Steven Gill  wrote:

> I am going to take the silence as lazy consensus. I will make sure to
> include the new file plugin as well.
>
> I will make sure to have a blog post of changes to review before I publish.
>
> -Steve
>
>
>
> On Mon, Feb 3, 2014 at 10:33 AM, Steven Gill 
> wrote:
>
> > Hey All,
> >
> > What is the general feeling on me moving forward with a plugins release
> > today? I could start the process this afternoon if there aren't any
> > objections or concerns.
> >
> > Are there any plugins that shouldn't be released?
> >
>

Re: Plugins Release!

[Steven Gill]

I am going to take the silence as lazy consensus. I will make sure to
include the new file plugin as well.

I will make sure to have a blog post of changes to review before I publish.

-Steve



On Mon, Feb 3, 2014 at 10:33 AM, Steven Gill  wrote:

> Hey All,
>
> What is the general feeling on me moving forward with a plugins release
> today? I could start the process this afternoon if there aren't any
> objections or concerns.
>
> Are there any plugins that shouldn't be released?
>

Re: plugins release

[Andrew Grieve]

No one's announced their intent to do one yet that I've seen.


On Thu, Jan 16, 2014 at 2:17 PM, Herm Wong wrote:

> Are we planning on a plugin release soon?
> There have been quite a few commits for FirefoxOS that need to be released
> into the main branch.

Re: Plugins Release Tomorrow

[Andrew Grieve]

Going to try and do this today :)


On Fri, Dec 20, 2013 at 1:33 PM, Ian Clelland wrote:

> That sounds reasonable. There isn't a huge rush on it.
>
>
> On Fri, Dec 20, 2013 at 10:54 AM, Andrew Grieve  >wrote:
>
> > Well, I didn't do this yesterday and don't want to do a Friday release,
> so
> > I'll do this Monday instead.
> >
> > I'll skip File plugin again until someone can test WP.
> >
> >
> > On Thu, Dec 19, 2013 at 1:40 AM, purplecabbage  > >wrote:
> >
> > > I have not. Someone needs to test the impact on windows phone before
> > > releasing this. I am away until the new year, so I cannot.
> > >
> > > Merry ho ho !
> > >
> > > Sent from my iPhone
> > >
> > > > On Dec 18, 2013, at 7:43 PM, Ian Clelland 
> > > wrote:
> > > >
> > > > I think the file plugin is good -- we should be bumping the major
> with
> > > this
> > > > one.
> > > >
> > > > Has anyone else had a chance to test it out?
> > > >
> > > > We should coordinate reverting 692f1fb with the push of file 1.0 to
> > npm;
> > > > I'm not sure how the timing on that works, but I'd like the pushed
> > > version
> > > > of file-transfer to explicitly depend on the new version of file.
> > > >
> > > >
> > > > On Wed, Dec 18, 2013 at 10:13 PM, Andrew Grieve <
> agri...@chromium.org
> > > >wrote:
> > > >
> > > >> I'd like to do one in order to add all of the doc/index.md files to
> > > >> master branches. Lots of other things in there as well:
> > > >>
> > > >>
> > > >> agrieve@agrieve-macbookpro ~/git/cordova$ ./cordova-coho/coho
> > > repo-status
> > > >> -r plugins -b dev --branch2 master --no-diff | grep -v CB-5658 |
> grep
> > -v
> > > >> 5565
> > > >> ./cordova-plugin-camera/ = cordova-plugin-camera on branch dev
> (vs
> > > >> master): Commits exist.
> > > >> 2437c40 CB-2442 CB-2419 Use
> > > >> Windows.Storage.ApplicationData.current.localFolder, instead of
> > writing
> > > to
> > > >> app package.
> > > >> ccd59e6 [BlackBerry10] Adding platform level permissions
> > > >> 6f4fef8 CB-5599 Android: Catch and ignore OutOfMemoryError in
> > > >> getRotatedBitmap()
> > > >> ./cordova-plugin-device/ = cordova-plugin-device on branch dev
> (vs
> > > >> master): Commits exist.
> > > >> 695272e CB-5504: Moving Telephony Logic out of Device
> > > >> ./cordova-plugin-dialogs/  cordova-plugin-dialogs on branch dev
> > (vs
> > > >> master): Commits exist.
> > > >> b44c138 move images from css to img
> > > >> 96c5fa7 CB-3762 Change prompt default to empty string
> > > >> ./cordova-plugin-file-transfer/ = cordova-plugin-file-transfer on
> > branch
> > > >> dev (vs master): Commits exist.
> > > >> 692f1fb Remove @1 designation from file plugin dependency until
> pushed
> > > to
> > > >> npm
> > > >> 647dad7 CB-5466: Update to work with filesystem URLs
> > > >> ./cordova-plugin-file/ === cordova-plugin-file on branch dev (vs
> > > >> master): Commits exist.
> > > >> eb28b7a CB-5403: Backwards-compatibility with file:// urls where
> > > possible
> > > >> a2b9073 CB-5407: Fixes for ContentFilesystem
> > > >> 83a867c Android: Add method for testing backwards-compatibility of
> > > >> filetransfer plugin
> > > >> 4c44780 iOS: Add method for testing backwards-compatiblity of
> > > filetransfer
> > > >> plugin
> > > >> 6f52e3b Android: Updates to allow FileTransfer to continue to work
> > > >> 6d0dad6 Android: Clean up unclosed file objects
> > > >> 0a6adf0 Merge branch "android-file" into dev
> > > >> 2550617 CB-5407: Cleanup
> > > >> 9f3bb54 CB-5407: Add new Android source files to plugin.xml
> > > >> ed4a8d7 CB-5407: Move read, write and truncate methods into modules
> > > >> 4859149 CB-5407: Move copy/move methods into FS modules
> > > >> 02e82a5 CB-5407: Move getParent into FS modules
> > > >> 06725c2 CB-5407: Move getmetadata methods into FS modules
> > > >> 85945d8 CB-5407: Move readdir methods into FS modules
> > > >> 919f99f CB-5407: Move remove methods into FS modules
> > > >> 0d0af8f CB-5407: Move getFile into FS modules
> > > >> 30988f7 CB-5407: Start refactoring android code: Modular
> filesystems,
> > > rfs,
> > > >> rlfsurl
> > > >> 225c905 CB-5407: Update android JS to use FS urls
> > > >> 7872b9c CB-5532 Fix
> > > >> cd7d925 CB-5405: Use URL formatting for Entry.toURL
> > > >> 95677c4 Log file path for File exceptions.
> > > >> 6b0ab74 Partial fix for iOS File compatibility with previous
> > > fileTransfer
> > > >> plugin
> > > >> 86f3446 Merge branch 'CB-5532' of
> > > >> https://github.com/sgrebnov/cordova-plugin-file into dev
> > > >> e0f59bd Merge branch 'CB-5531' of
> > > >> https://github.com/sgrebnov/cordova-plugin-file into dev
> > > >> ef636d9 CB-5532 WP8. Add binary data support to FileWriter
> > > >> f2f22ab CB-5531 WP8. File Api readAsText incorrectly handles
> position
> > > args
> > > >> 9a5278b added ubuntu support
> > > >> bb626c6 Merge branch 'dev' of github.com:
> > > archananaik/cordova-plugin-file
> > > >> into dev
> > > >> 093b084 CB-5118 [BlackBerry10] Add check for undefined error handler
> > > >> 5a1a7a2 [ubu

Re: Plugins Release Tomorrow

[Ian Clelland]

That sounds reasonable. There isn't a huge rush on it.


On Fri, Dec 20, 2013 at 10:54 AM, Andrew Grieve wrote:

> Well, I didn't do this yesterday and don't want to do a Friday release, so
> I'll do this Monday instead.
>
> I'll skip File plugin again until someone can test WP.
>
>
> On Thu, Dec 19, 2013 at 1:40 AM, purplecabbage  >wrote:
>
> > I have not. Someone needs to test the impact on windows phone before
> > releasing this. I am away until the new year, so I cannot.
> >
> > Merry ho ho !
> >
> > Sent from my iPhone
> >
> > > On Dec 18, 2013, at 7:43 PM, Ian Clelland 
> > wrote:
> > >
> > > I think the file plugin is good -- we should be bumping the major with
> > this
> > > one.
> > >
> > > Has anyone else had a chance to test it out?
> > >
> > > We should coordinate reverting 692f1fb with the push of file 1.0 to
> npm;
> > > I'm not sure how the timing on that works, but I'd like the pushed
> > version
> > > of file-transfer to explicitly depend on the new version of file.
> > >
> > >
> > > On Wed, Dec 18, 2013 at 10:13 PM, Andrew Grieve  > >wrote:
> > >
> > >> I'd like to do one in order to add all of the doc/index.md files to
> > >> master branches. Lots of other things in there as well:
> > >>
> > >>
> > >> agrieve@agrieve-macbookpro ~/git/cordova$ ./cordova-coho/coho
> > repo-status
> > >> -r plugins -b dev --branch2 master --no-diff | grep -v CB-5658 | grep
> -v
> > >> 5565
> > >> ./cordova-plugin-camera/ = cordova-plugin-camera on branch dev (vs
> > >> master): Commits exist.
> > >> 2437c40 CB-2442 CB-2419 Use
> > >> Windows.Storage.ApplicationData.current.localFolder, instead of
> writing
> > to
> > >> app package.
> > >> ccd59e6 [BlackBerry10] Adding platform level permissions
> > >> 6f4fef8 CB-5599 Android: Catch and ignore OutOfMemoryError in
> > >> getRotatedBitmap()
> > >> ./cordova-plugin-device/ = cordova-plugin-device on branch dev (vs
> > >> master): Commits exist.
> > >> 695272e CB-5504: Moving Telephony Logic out of Device
> > >> ./cordova-plugin-dialogs/  cordova-plugin-dialogs on branch dev
> (vs
> > >> master): Commits exist.
> > >> b44c138 move images from css to img
> > >> 96c5fa7 CB-3762 Change prompt default to empty string
> > >> ./cordova-plugin-file-transfer/ = cordova-plugin-file-transfer on
> branch
> > >> dev (vs master): Commits exist.
> > >> 692f1fb Remove @1 designation from file plugin dependency until pushed
> > to
> > >> npm
> > >> 647dad7 CB-5466: Update to work with filesystem URLs
> > >> ./cordova-plugin-file/ === cordova-plugin-file on branch dev (vs
> > >> master): Commits exist.
> > >> eb28b7a CB-5403: Backwards-compatibility with file:// urls where
> > possible
> > >> a2b9073 CB-5407: Fixes for ContentFilesystem
> > >> 83a867c Android: Add method for testing backwards-compatibility of
> > >> filetransfer plugin
> > >> 4c44780 iOS: Add method for testing backwards-compatiblity of
> > filetransfer
> > >> plugin
> > >> 6f52e3b Android: Updates to allow FileTransfer to continue to work
> > >> 6d0dad6 Android: Clean up unclosed file objects
> > >> 0a6adf0 Merge branch "android-file" into dev
> > >> 2550617 CB-5407: Cleanup
> > >> 9f3bb54 CB-5407: Add new Android source files to plugin.xml
> > >> ed4a8d7 CB-5407: Move read, write and truncate methods into modules
> > >> 4859149 CB-5407: Move copy/move methods into FS modules
> > >> 02e82a5 CB-5407: Move getParent into FS modules
> > >> 06725c2 CB-5407: Move getmetadata methods into FS modules
> > >> 85945d8 CB-5407: Move readdir methods into FS modules
> > >> 919f99f CB-5407: Move remove methods into FS modules
> > >> 0d0af8f CB-5407: Move getFile into FS modules
> > >> 30988f7 CB-5407: Start refactoring android code: Modular filesystems,
> > rfs,
> > >> rlfsurl
> > >> 225c905 CB-5407: Update android JS to use FS urls
> > >> 7872b9c CB-5532 Fix
> > >> cd7d925 CB-5405: Use URL formatting for Entry.toURL
> > >> 95677c4 Log file path for File exceptions.
> > >> 6b0ab74 Partial fix for iOS File compatibility with previous
> > fileTransfer
> > >> plugin
> > >> 86f3446 Merge branch 'CB-5532' of
> > >> https://github.com/sgrebnov/cordova-plugin-file into dev
> > >> e0f59bd Merge branch 'CB-5531' of
> > >> https://github.com/sgrebnov/cordova-plugin-file into dev
> > >> ef636d9 CB-5532 WP8. Add binary data support to FileWriter
> > >> f2f22ab CB-5531 WP8. File Api readAsText incorrectly handles position
> > args
> > >> 9a5278b added ubuntu support
> > >> bb626c6 Merge branch 'dev' of github.com:
> > archananaik/cordova-plugin-file
> > >> into dev
> > >> 093b084 CB-5118 [BlackBerry10] Add check for undefined error handler
> > >> 5a1a7a2 [ubuntu] use cordova/exec/proxy
> > >> 5a4d9ad CB-5406: Extend public API for dependent plugins
> > >> 8d7e261 CB-5403: Bump File plugin major version
> > >> 7bb3977 CB-5406: Split iOS file plugin into modules
> > >> 64187ca CB-5406: Factor out filesystem providers in iOS
> > >> b8c4f85 CB-5408: Add handler for filesystem:// urls
> > >> b3b6a83 CB-5406: Update iOS native

Re: Plugins Release Tomorrow

[Andrew Grieve]

Well, I didn't do this yesterday and don't want to do a Friday release, so
I'll do this Monday instead.

I'll skip File plugin again until someone can test WP.


On Thu, Dec 19, 2013 at 1:40 AM, purplecabbage wrote:

> I have not. Someone needs to test the impact on windows phone before
> releasing this. I am away until the new year, so I cannot.
>
> Merry ho ho !
>
> Sent from my iPhone
>
> > On Dec 18, 2013, at 7:43 PM, Ian Clelland 
> wrote:
> >
> > I think the file plugin is good -- we should be bumping the major with
> this
> > one.
> >
> > Has anyone else had a chance to test it out?
> >
> > We should coordinate reverting 692f1fb with the push of file 1.0 to npm;
> > I'm not sure how the timing on that works, but I'd like the pushed
> version
> > of file-transfer to explicitly depend on the new version of file.
> >
> >
> > On Wed, Dec 18, 2013 at 10:13 PM, Andrew Grieve  >wrote:
> >
> >> I'd like to do one in order to add all of the doc/index.md files to
> >> master branches. Lots of other things in there as well:
> >>
> >>
> >> agrieve@agrieve-macbookpro ~/git/cordova$ ./cordova-coho/coho
> repo-status
> >> -r plugins -b dev --branch2 master --no-diff | grep -v CB-5658 | grep -v
> >> 5565
> >> ./cordova-plugin-camera/ = cordova-plugin-camera on branch dev (vs
> >> master): Commits exist.
> >> 2437c40 CB-2442 CB-2419 Use
> >> Windows.Storage.ApplicationData.current.localFolder, instead of writing
> to
> >> app package.
> >> ccd59e6 [BlackBerry10] Adding platform level permissions
> >> 6f4fef8 CB-5599 Android: Catch and ignore OutOfMemoryError in
> >> getRotatedBitmap()
> >> ./cordova-plugin-device/ = cordova-plugin-device on branch dev (vs
> >> master): Commits exist.
> >> 695272e CB-5504: Moving Telephony Logic out of Device
> >> ./cordova-plugin-dialogs/  cordova-plugin-dialogs on branch dev (vs
> >> master): Commits exist.
> >> b44c138 move images from css to img
> >> 96c5fa7 CB-3762 Change prompt default to empty string
> >> ./cordova-plugin-file-transfer/ = cordova-plugin-file-transfer on branch
> >> dev (vs master): Commits exist.
> >> 692f1fb Remove @1 designation from file plugin dependency until pushed
> to
> >> npm
> >> 647dad7 CB-5466: Update to work with filesystem URLs
> >> ./cordova-plugin-file/ === cordova-plugin-file on branch dev (vs
> >> master): Commits exist.
> >> eb28b7a CB-5403: Backwards-compatibility with file:// urls where
> possible
> >> a2b9073 CB-5407: Fixes for ContentFilesystem
> >> 83a867c Android: Add method for testing backwards-compatibility of
> >> filetransfer plugin
> >> 4c44780 iOS: Add method for testing backwards-compatiblity of
> filetransfer
> >> plugin
> >> 6f52e3b Android: Updates to allow FileTransfer to continue to work
> >> 6d0dad6 Android: Clean up unclosed file objects
> >> 0a6adf0 Merge branch "android-file" into dev
> >> 2550617 CB-5407: Cleanup
> >> 9f3bb54 CB-5407: Add new Android source files to plugin.xml
> >> ed4a8d7 CB-5407: Move read, write and truncate methods into modules
> >> 4859149 CB-5407: Move copy/move methods into FS modules
> >> 02e82a5 CB-5407: Move getParent into FS modules
> >> 06725c2 CB-5407: Move getmetadata methods into FS modules
> >> 85945d8 CB-5407: Move readdir methods into FS modules
> >> 919f99f CB-5407: Move remove methods into FS modules
> >> 0d0af8f CB-5407: Move getFile into FS modules
> >> 30988f7 CB-5407: Start refactoring android code: Modular filesystems,
> rfs,
> >> rlfsurl
> >> 225c905 CB-5407: Update android JS to use FS urls
> >> 7872b9c CB-5532 Fix
> >> cd7d925 CB-5405: Use URL formatting for Entry.toURL
> >> 95677c4 Log file path for File exceptions.
> >> 6b0ab74 Partial fix for iOS File compatibility with previous
> fileTransfer
> >> plugin
> >> 86f3446 Merge branch 'CB-5532' of
> >> https://github.com/sgrebnov/cordova-plugin-file into dev
> >> e0f59bd Merge branch 'CB-5531' of
> >> https://github.com/sgrebnov/cordova-plugin-file into dev
> >> ef636d9 CB-5532 WP8. Add binary data support to FileWriter
> >> f2f22ab CB-5531 WP8. File Api readAsText incorrectly handles position
> args
> >> 9a5278b added ubuntu support
> >> bb626c6 Merge branch 'dev' of github.com:
> archananaik/cordova-plugin-file
> >> into dev
> >> 093b084 CB-5118 [BlackBerry10] Add check for undefined error handler
> >> 5a1a7a2 [ubuntu] use cordova/exec/proxy
> >> 5a4d9ad CB-5406: Extend public API for dependent plugins
> >> 8d7e261 CB-5403: Bump File plugin major version
> >> 7bb3977 CB-5406: Split iOS file plugin into modules
> >> 64187ca CB-5406: Factor out filesystem providers in iOS
> >> b8c4f85 CB-5408: Add handler for filesystem:// urls
> >> b3b6a83 CB-5406: Update iOS native code to use filesystem URLs
> internally
> >> 1dfdf0f CB-5405: Update JS code to use URLs exclusively
> >> 43c901a CB-4816 Fix file creation outside sandbox for BB10
> >> ab9de01 [ubuntu] change location of persistent dir
> >> 396cbeb 1. Added amazon-fireos platform 2. Change to use amazon-fireos
> as
> >> a platform is the user agent string cont

Re: Plugins Release Tomorrow

[purplecabbage]

I have not. Someone needs to test the impact on windows phone before releasing 
this. I am away until the new year, so I cannot. 

Merry ho ho !

Sent from my iPhone

> On Dec 18, 2013, at 7:43 PM, Ian Clelland  wrote:
> 
> I think the file plugin is good -- we should be bumping the major with this
> one.
> 
> Has anyone else had a chance to test it out?
> 
> We should coordinate reverting 692f1fb with the push of file 1.0 to npm;
> I'm not sure how the timing on that works, but I'd like the pushed version
> of file-transfer to explicitly depend on the new version of file.
> 
> 
> On Wed, Dec 18, 2013 at 10:13 PM, Andrew Grieve wrote:
> 
>> I'd like to do one in order to add all of the doc/index.md files to
>> master branches. Lots of other things in there as well:
>> 
>> 
>> agrieve@agrieve-macbookpro ~/git/cordova$ ./cordova-coho/coho repo-status
>> -r plugins -b dev --branch2 master --no-diff | grep -v CB-5658 | grep -v
>> 5565
>> ./cordova-plugin-camera/ = cordova-plugin-camera on branch dev (vs
>> master): Commits exist.
>> 2437c40 CB-2442 CB-2419 Use
>> Windows.Storage.ApplicationData.current.localFolder, instead of writing to
>> app package.
>> ccd59e6 [BlackBerry10] Adding platform level permissions
>> 6f4fef8 CB-5599 Android: Catch and ignore OutOfMemoryError in
>> getRotatedBitmap()
>> ./cordova-plugin-device/ = cordova-plugin-device on branch dev (vs
>> master): Commits exist.
>> 695272e CB-5504: Moving Telephony Logic out of Device
>> ./cordova-plugin-dialogs/  cordova-plugin-dialogs on branch dev (vs
>> master): Commits exist.
>> b44c138 move images from css to img
>> 96c5fa7 CB-3762 Change prompt default to empty string
>> ./cordova-plugin-file-transfer/ = cordova-plugin-file-transfer on branch
>> dev (vs master): Commits exist.
>> 692f1fb Remove @1 designation from file plugin dependency until pushed to
>> npm
>> 647dad7 CB-5466: Update to work with filesystem URLs
>> ./cordova-plugin-file/ === cordova-plugin-file on branch dev (vs
>> master): Commits exist.
>> eb28b7a CB-5403: Backwards-compatibility with file:// urls where possible
>> a2b9073 CB-5407: Fixes for ContentFilesystem
>> 83a867c Android: Add method for testing backwards-compatibility of
>> filetransfer plugin
>> 4c44780 iOS: Add method for testing backwards-compatiblity of filetransfer
>> plugin
>> 6f52e3b Android: Updates to allow FileTransfer to continue to work
>> 6d0dad6 Android: Clean up unclosed file objects
>> 0a6adf0 Merge branch "android-file" into dev
>> 2550617 CB-5407: Cleanup
>> 9f3bb54 CB-5407: Add new Android source files to plugin.xml
>> ed4a8d7 CB-5407: Move read, write and truncate methods into modules
>> 4859149 CB-5407: Move copy/move methods into FS modules
>> 02e82a5 CB-5407: Move getParent into FS modules
>> 06725c2 CB-5407: Move getmetadata methods into FS modules
>> 85945d8 CB-5407: Move readdir methods into FS modules
>> 919f99f CB-5407: Move remove methods into FS modules
>> 0d0af8f CB-5407: Move getFile into FS modules
>> 30988f7 CB-5407: Start refactoring android code: Modular filesystems, rfs,
>> rlfsurl
>> 225c905 CB-5407: Update android JS to use FS urls
>> 7872b9c CB-5532 Fix
>> cd7d925 CB-5405: Use URL formatting for Entry.toURL
>> 95677c4 Log file path for File exceptions.
>> 6b0ab74 Partial fix for iOS File compatibility with previous fileTransfer
>> plugin
>> 86f3446 Merge branch 'CB-5532' of
>> https://github.com/sgrebnov/cordova-plugin-file into dev
>> e0f59bd Merge branch 'CB-5531' of
>> https://github.com/sgrebnov/cordova-plugin-file into dev
>> ef636d9 CB-5532 WP8. Add binary data support to FileWriter
>> f2f22ab CB-5531 WP8. File Api readAsText incorrectly handles position args
>> 9a5278b added ubuntu support
>> bb626c6 Merge branch 'dev' of github.com:archananaik/cordova-plugin-file
>> into dev
>> 093b084 CB-5118 [BlackBerry10] Add check for undefined error handler
>> 5a1a7a2 [ubuntu] use cordova/exec/proxy
>> 5a4d9ad CB-5406: Extend public API for dependent plugins
>> 8d7e261 CB-5403: Bump File plugin major version
>> 7bb3977 CB-5406: Split iOS file plugin into modules
>> 64187ca CB-5406: Factor out filesystem providers in iOS
>> b8c4f85 CB-5408: Add handler for filesystem:// urls
>> b3b6a83 CB-5406: Update iOS native code to use filesystem URLs internally
>> 1dfdf0f CB-5405: Update JS code to use URLs exclusively
>> 43c901a CB-4816 Fix file creation outside sandbox for BB10
>> ab9de01 [ubuntu] change location of persistent dir
>> 396cbeb 1. Added amazon-fireos platform 2. Change to use amazon-fireos as
>> a platform is the user agent string contains 'cordova-amazon-fireos'
>> ca2c4e2 CB-5188:
>> af8d7c2 add ubuntu platform
>> ./cordova-plugin-geolocation/ = cordova-plugin-geolocation on branch dev
>> (vs master): Commits exist.
>> 179993f windows8. adds missing reference to PositionError (w/o it the app
>> crashes)
>> 2ecd9d1 Removing incorrectly added closing comments for wp7 platform in
>> plugin.xml
>> ./cordova-plugin-inappbrowser/ = cordova-plugin-inappbrowser on

Re: Plugins Release Tomorrow

[Ian Clelland]

I think the file plugin is good -- we should be bumping the major with this
one.

Has anyone else had a chance to test it out?

We should coordinate reverting 692f1fb with the push of file 1.0 to npm;
I'm not sure how the timing on that works, but I'd like the pushed version
of file-transfer to explicitly depend on the new version of file.


On Wed, Dec 18, 2013 at 10:13 PM, Andrew Grieve wrote:

> I'd like to do one in order to add all of the doc/index.md files to
> master branches. Lots of other things in there as well:
>
>
> agrieve@agrieve-macbookpro ~/git/cordova$ ./cordova-coho/coho repo-status
> -r plugins -b dev --branch2 master --no-diff | grep -v CB-5658 | grep -v
> 5565
> ./cordova-plugin-camera/ = cordova-plugin-camera on branch dev (vs
> master): Commits exist.
> 2437c40 CB-2442 CB-2419 Use
> Windows.Storage.ApplicationData.current.localFolder, instead of writing to
> app package.
> ccd59e6 [BlackBerry10] Adding platform level permissions
> 6f4fef8 CB-5599 Android: Catch and ignore OutOfMemoryError in
> getRotatedBitmap()
> ./cordova-plugin-device/ = cordova-plugin-device on branch dev (vs
> master): Commits exist.
> 695272e CB-5504: Moving Telephony Logic out of Device
> ./cordova-plugin-dialogs/  cordova-plugin-dialogs on branch dev (vs
> master): Commits exist.
> b44c138 move images from css to img
>  96c5fa7 CB-3762 Change prompt default to empty string
> ./cordova-plugin-file-transfer/ = cordova-plugin-file-transfer on branch
> dev (vs master): Commits exist.
> 692f1fb Remove @1 designation from file plugin dependency until pushed to
> npm
> 647dad7 CB-5466: Update to work with filesystem URLs
> ./cordova-plugin-file/ === cordova-plugin-file on branch dev (vs
> master): Commits exist.
> eb28b7a CB-5403: Backwards-compatibility with file:// urls where possible
> a2b9073 CB-5407: Fixes for ContentFilesystem
> 83a867c Android: Add method for testing backwards-compatibility of
> filetransfer plugin
> 4c44780 iOS: Add method for testing backwards-compatiblity of filetransfer
> plugin
> 6f52e3b Android: Updates to allow FileTransfer to continue to work
> 6d0dad6 Android: Clean up unclosed file objects
> 0a6adf0 Merge branch "android-file" into dev
> 2550617 CB-5407: Cleanup
> 9f3bb54 CB-5407: Add new Android source files to plugin.xml
> ed4a8d7 CB-5407: Move read, write and truncate methods into modules
> 4859149 CB-5407: Move copy/move methods into FS modules
> 02e82a5 CB-5407: Move getParent into FS modules
> 06725c2 CB-5407: Move getmetadata methods into FS modules
> 85945d8 CB-5407: Move readdir methods into FS modules
> 919f99f CB-5407: Move remove methods into FS modules
> 0d0af8f CB-5407: Move getFile into FS modules
> 30988f7 CB-5407: Start refactoring android code: Modular filesystems, rfs,
> rlfsurl
> 225c905 CB-5407: Update android JS to use FS urls
> 7872b9c CB-5532 Fix
> cd7d925 CB-5405: Use URL formatting for Entry.toURL
> 95677c4 Log file path for File exceptions.
> 6b0ab74 Partial fix for iOS File compatibility with previous fileTransfer
> plugin
> 86f3446 Merge branch 'CB-5532' of
> https://github.com/sgrebnov/cordova-plugin-file into dev
> e0f59bd Merge branch 'CB-5531' of
> https://github.com/sgrebnov/cordova-plugin-file into dev
> ef636d9 CB-5532 WP8. Add binary data support to FileWriter
> f2f22ab CB-5531 WP8. File Api readAsText incorrectly handles position args
> 9a5278b added ubuntu support
> bb626c6 Merge branch 'dev' of github.com:archananaik/cordova-plugin-file
> into dev
> 093b084 CB-5118 [BlackBerry10] Add check for undefined error handler
> 5a1a7a2 [ubuntu] use cordova/exec/proxy
> 5a4d9ad CB-5406: Extend public API for dependent plugins
> 8d7e261 CB-5403: Bump File plugin major version
> 7bb3977 CB-5406: Split iOS file plugin into modules
> 64187ca CB-5406: Factor out filesystem providers in iOS
> b8c4f85 CB-5408: Add handler for filesystem:// urls
> b3b6a83 CB-5406: Update iOS native code to use filesystem URLs internally
> 1dfdf0f CB-5405: Update JS code to use URLs exclusively
> 43c901a CB-4816 Fix file creation outside sandbox for BB10
> ab9de01 [ubuntu] change location of persistent dir
> 396cbeb 1. Added amazon-fireos platform 2. Change to use amazon-fireos as
> a platform is the user agent string contains 'cordova-amazon-fireos'
> ca2c4e2 CB-5188:
> af8d7c2 add ubuntu platform
> ./cordova-plugin-geolocation/ = cordova-plugin-geolocation on branch dev
> (vs master): Commits exist.
> 179993f windows8. adds missing reference to PositionError (w/o it the app
> crashes)
> 2ecd9d1 Removing incorrectly added closing comments for wp7 platform in
> plugin.xml
> ./cordova-plugin-inappbrowser/ = cordova-plugin-inappbrowser on branch dev
> (vs master): Commits exist.
> f75b308 CB-5594 Add disallowoverscroll option.
> 25d152b CB-5595 Rename "toolbarbarpostion" -> "toolbarposition"
> 4aeaf81 CB-5595 Fixed the positioning and autoresizing for certain
> rotation scenarios.
> 20611ef CB-5595 Add toolbarposition=top option.
> e819041 Apply CB-5193 to InAppBro

RE: Plugins Release today

[Sergey Grebnov (Akvelon)]

Thank you, Steve! It is definitely a good reserve way to proceed,  but I think 
we should target to single post and no changes after so I'm discussing options 
with my colleagues to see if there is an easy way to achieve this. As for the 
current release let's keep it as is in this situation. Thank you!

-Sergey
-Original Message-
From: Steven Gill [mailto:stevengil...@gmail.com] 
Sent: Thursday, December 5, 2013 10:52 PM
To: dev@cordova.apache.org
Subject: Re: Plugins Release today

Hey Sergey,

We can still add the lines. The File plugin didn't get released with this 
release. Feel free to share the line you want added about contacts with me and 
I can add it to the blog post. You are always welcomed to go edit the blog post 
by pulling down the site if you want to go that route instead.

-Steve


On Thu, Dec 5, 2013 at 12:38 AM, Sergey Grebnov (Akvelon) < 
v-seg...@microsoft.com> wrote:

> Congrats and thx!
>
> I have the only following concern - since release info review process 
> goes very fast (during my night) I can't participate in it :) For 
> example for
> WP8 I would love to add one line note about important fixes in 
> Contacts api  and File api. I'll figure out how we can improve this 
> with Jesse and my US team.
>
> Thx!
> Sergey
> -Original Message-
> From: Carlos Santana [mailto:csantan...@gmail.com]
> Sent: Thursday, December 5, 2013 8:44 AM
> To: dev@cordova.apache.org
> Subject: Re: Plugins Release today
>
> Thanks Steve!
>
>
> On Wed, Dec 4, 2013 at 11:07 PM, Andrew Grieve 
> wrote:
>
> > Great job! Thanks indeed!
> >
> >
> > On Wed, Dec 4, 2013 at 11:01 PM, Brian LeRoux  wrote:
> >
> > > thx Steve!
> > >
> > >
> > > On Thu, Dec 5, 2013 at 2:47 PM, Steven Gill 
> > > 
> > > wrote:
> > >
> > > > Plugins have been released!
> > > >
> > > > http://cordova.apache.org/news/2013/12/04/plugins-release.html
> > > > https://twitter.com/apachecordova/status/408441655222476800
> > > >
> > > > device-motion and battery-status haven't been published yet due 
> > > > to a
> > > error
> > > > I ran into with plugman publish. I have pinged Anis to take a look.
> > They
> > > > will be up asap.
> > > >
> > > > File also didn't get released today. It will hopefully be ready 
> > > > to get released next week before 3.3.0 final!
> > > >
> > > > Cheers,
> > > > -Steve
> > > >
> > > >
> > > > On Wed, Dec 4, 2013 at 12:55 PM, Josh Soref 
> > > > 
> > > wrote:
> > > >
> > > > > > I suspect we almost always want to test new feature against
> > > tip-of-tree
> > > > > > (I guess thats master).
> > > > >
> > > > > For what I believe are hysterical reasons, I think it's 
> > > > > sometimes
> > > called
> > > > > "dev".
> > > > >
> > > > > > So being able to run that but replace some of the
> > > > > repos with a different branch would be awesome.
> > > > >
> > > > > > What if we used the convention of naming feature branches in 
> > > > > > all
> > the
> > > > > applicable repos the same thing,
> > > > > > that way we can poke CI with a single name and it would 
> > > > > > check out
> > > that
> > > > > branch on all the repos if it existed?
> > > > > --
> > > > > --
> > > > > - This transmission (including any attachments) may 
> > > > > contain
> > confidential
> > > > > information, privileged material (including material protected 
> > > > > by the solicitor-client or other applicable privileges), or 
> > > > > constitute
> > > > non-public
> > > > > information. Any use of this information by anyone other than 
> > > > > the
> > > > intended
> > > > > recipient is prohibited. If you have received this 
> > > > > transmission in
> > > error,
> > > > > please immediately reply to the sender and delete this 
> > > > > information
> > from
> > > > > your system. Use, dissemination, distribution, or reproduction 
> > > > > of
> > this
> > > > > transmission by unintended recipients is not authorized and 
> > > > > may be
> > > > unlawful.
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Carlos Santana
> 
>

Re: Plugins Release today

[Steven Gill]

Hey Sergey,

We can still add the lines. The File plugin didn't get released with this
release. Feel free to share the line you want added about contacts with me
and I can add it to the blog post. You are always welcomed to go edit the
blog post by pulling down the site if you want to go that route instead.

-Steve


On Thu, Dec 5, 2013 at 12:38 AM, Sergey Grebnov (Akvelon) <
v-seg...@microsoft.com> wrote:

> Congrats and thx!
>
> I have the only following concern - since release info review process goes
> very fast (during my night) I can't participate in it :) For example for
> WP8 I would love to add one line note about important fixes in Contacts api
>  and File api. I'll figure out how we can improve this with Jesse and my US
> team.
>
> Thx!
> Sergey
> -Original Message-
> From: Carlos Santana [mailto:csantan...@gmail.com]
> Sent: Thursday, December 5, 2013 8:44 AM
> To: dev@cordova.apache.org
> Subject: Re: Plugins Release today
>
> Thanks Steve!
>
>
> On Wed, Dec 4, 2013 at 11:07 PM, Andrew Grieve 
> wrote:
>
> > Great job! Thanks indeed!
> >
> >
> > On Wed, Dec 4, 2013 at 11:01 PM, Brian LeRoux  wrote:
> >
> > > thx Steve!
> > >
> > >
> > > On Thu, Dec 5, 2013 at 2:47 PM, Steven Gill 
> > > wrote:
> > >
> > > > Plugins have been released!
> > > >
> > > > http://cordova.apache.org/news/2013/12/04/plugins-release.html
> > > > https://twitter.com/apachecordova/status/408441655222476800
> > > >
> > > > device-motion and battery-status haven't been published yet due to
> > > > a
> > > error
> > > > I ran into with plugman publish. I have pinged Anis to take a look.
> > They
> > > > will be up asap.
> > > >
> > > > File also didn't get released today. It will hopefully be ready to
> > > > get released next week before 3.3.0 final!
> > > >
> > > > Cheers,
> > > > -Steve
> > > >
> > > >
> > > > On Wed, Dec 4, 2013 at 12:55 PM, Josh Soref
> > > > 
> > > wrote:
> > > >
> > > > > > I suspect we almost always want to test new feature against
> > > tip-of-tree
> > > > > > (I guess thats master).
> > > > >
> > > > > For what I believe are hysterical reasons, I think it's
> > > > > sometimes
> > > called
> > > > > "dev".
> > > > >
> > > > > > So being able to run that but replace some of the
> > > > > repos with a different branch would be awesome.
> > > > >
> > > > > > What if we used the convention of naming feature branches in
> > > > > > all
> > the
> > > > > applicable repos the same thing,
> > > > > > that way we can poke CI with a single name and it would check
> > > > > > out
> > > that
> > > > > branch on all the repos if it existed?
> > > > > 
> > > > > - This transmission (including any attachments) may contain
> > confidential
> > > > > information, privileged material (including material protected
> > > > > by the solicitor-client or other applicable privileges), or
> > > > > constitute
> > > > non-public
> > > > > information. Any use of this information by anyone other than
> > > > > the
> > > > intended
> > > > > recipient is prohibited. If you have received this transmission
> > > > > in
> > > error,
> > > > > please immediately reply to the sender and delete this
> > > > > information
> > from
> > > > > your system. Use, dissemination, distribution, or reproduction
> > > > > of
> > this
> > > > > transmission by unintended recipients is not authorized and may
> > > > > be
> > > > unlawful.
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Carlos Santana
> 
>

RE: Plugins Release today

[Sergey Grebnov (Akvelon)]

Congrats and thx!

I have the only following concern - since release info review process goes very 
fast (during my night) I can't participate in it :) For example for WP8 I would 
love to add one line note about important fixes in Contacts api  and File api. 
I'll figure out how we can improve this with Jesse and my US team.

Thx!
Sergey
-Original Message-
From: Carlos Santana [mailto:csantan...@gmail.com] 
Sent: Thursday, December 5, 2013 8:44 AM
To: dev@cordova.apache.org
Subject: Re: Plugins Release today

Thanks Steve!


On Wed, Dec 4, 2013 at 11:07 PM, Andrew Grieve  wrote:

> Great job! Thanks indeed!
>
>
> On Wed, Dec 4, 2013 at 11:01 PM, Brian LeRoux  wrote:
>
> > thx Steve!
> >
> >
> > On Thu, Dec 5, 2013 at 2:47 PM, Steven Gill 
> > wrote:
> >
> > > Plugins have been released!
> > >
> > > http://cordova.apache.org/news/2013/12/04/plugins-release.html
> > > https://twitter.com/apachecordova/status/408441655222476800
> > >
> > > device-motion and battery-status haven't been published yet due to 
> > > a
> > error
> > > I ran into with plugman publish. I have pinged Anis to take a look.
> They
> > > will be up asap.
> > >
> > > File also didn't get released today. It will hopefully be ready to 
> > > get released next week before 3.3.0 final!
> > >
> > > Cheers,
> > > -Steve
> > >
> > >
> > > On Wed, Dec 4, 2013 at 12:55 PM, Josh Soref 
> > > 
> > wrote:
> > >
> > > > > I suspect we almost always want to test new feature against
> > tip-of-tree
> > > > > (I guess thats master).
> > > >
> > > > For what I believe are hysterical reasons, I think it's 
> > > > sometimes
> > called
> > > > "dev".
> > > >
> > > > > So being able to run that but replace some of the
> > > > repos with a different branch would be awesome.
> > > >
> > > > > What if we used the convention of naming feature branches in 
> > > > > all
> the
> > > > applicable repos the same thing,
> > > > > that way we can poke CI with a single name and it would check 
> > > > > out
> > that
> > > > branch on all the repos if it existed?
> > > > 
> > > > - This transmission (including any attachments) may contain
> confidential
> > > > information, privileged material (including material protected 
> > > > by the solicitor-client or other applicable privileges), or 
> > > > constitute
> > > non-public
> > > > information. Any use of this information by anyone other than 
> > > > the
> > > intended
> > > > recipient is prohibited. If you have received this transmission 
> > > > in
> > error,
> > > > please immediately reply to the sender and delete this 
> > > > information
> from
> > > > your system. Use, dissemination, distribution, or reproduction 
> > > > of
> this
> > > > transmission by unintended recipients is not authorized and may 
> > > > be
> > > unlawful.
> > > >
> > >
> >
>



--
Carlos Santana

Re: Plugins Release today

[Carlos Santana]

Thanks Steve!


On Wed, Dec 4, 2013 at 11:07 PM, Andrew Grieve  wrote:

> Great job! Thanks indeed!
>
>
> On Wed, Dec 4, 2013 at 11:01 PM, Brian LeRoux  wrote:
>
> > thx Steve!
> >
> >
> > On Thu, Dec 5, 2013 at 2:47 PM, Steven Gill 
> > wrote:
> >
> > > Plugins have been released!
> > >
> > > http://cordova.apache.org/news/2013/12/04/plugins-release.html
> > > https://twitter.com/apachecordova/status/408441655222476800
> > >
> > > device-motion and battery-status haven't been published yet due to a
> > error
> > > I ran into with plugman publish. I have pinged Anis to take a look.
> They
> > > will be up asap.
> > >
> > > File also didn't get released today. It will hopefully be ready to get
> > > released next week before 3.3.0 final!
> > >
> > > Cheers,
> > > -Steve
> > >
> > >
> > > On Wed, Dec 4, 2013 at 12:55 PM, Josh Soref 
> > wrote:
> > >
> > > > > I suspect we almost always want to test new feature against
> > tip-of-tree
> > > > > (I guess thats master).
> > > >
> > > > For what I believe are hysterical reasons, I think it's sometimes
> > called
> > > > "dev".
> > > >
> > > > > So being able to run that but replace some of the
> > > > repos with a different branch would be awesome.
> > > >
> > > > > What if we used the convention of naming feature branches in all
> the
> > > > applicable repos the same thing,
> > > > > that way we can poke CI with a single name and it would check out
> > that
> > > > branch on all the repos if it existed?
> > > > -
> > > > This transmission (including any attachments) may contain
> confidential
> > > > information, privileged material (including material protected by the
> > > > solicitor-client or other applicable privileges), or constitute
> > > non-public
> > > > information. Any use of this information by anyone other than the
> > > intended
> > > > recipient is prohibited. If you have received this transmission in
> > error,
> > > > please immediately reply to the sender and delete this information
> from
> > > > your system. Use, dissemination, distribution, or reproduction of
> this
> > > > transmission by unintended recipients is not authorized and may be
> > > unlawful.
> > > >
> > >
> >
>



-- 
Carlos Santana

Re: Plugins Release today

[Andrew Grieve]

Great job! Thanks indeed!


On Wed, Dec 4, 2013 at 11:01 PM, Brian LeRoux  wrote:

> thx Steve!
>
>
> On Thu, Dec 5, 2013 at 2:47 PM, Steven Gill 
> wrote:
>
> > Plugins have been released!
> >
> > http://cordova.apache.org/news/2013/12/04/plugins-release.html
> > https://twitter.com/apachecordova/status/408441655222476800
> >
> > device-motion and battery-status haven't been published yet due to a
> error
> > I ran into with plugman publish. I have pinged Anis to take a look. They
> > will be up asap.
> >
> > File also didn't get released today. It will hopefully be ready to get
> > released next week before 3.3.0 final!
> >
> > Cheers,
> > -Steve
> >
> >
> > On Wed, Dec 4, 2013 at 12:55 PM, Josh Soref 
> wrote:
> >
> > > > I suspect we almost always want to test new feature against
> tip-of-tree
> > > > (I guess thats master).
> > >
> > > For what I believe are hysterical reasons, I think it's sometimes
> called
> > > "dev".
> > >
> > > > So being able to run that but replace some of the
> > > repos with a different branch would be awesome.
> > >
> > > > What if we used the convention of naming feature branches in all the
> > > applicable repos the same thing,
> > > > that way we can poke CI with a single name and it would check out
> that
> > > branch on all the repos if it existed?
> > > -
> > > This transmission (including any attachments) may contain confidential
> > > information, privileged material (including material protected by the
> > > solicitor-client or other applicable privileges), or constitute
> > non-public
> > > information. Any use of this information by anyone other than the
> > intended
> > > recipient is prohibited. If you have received this transmission in
> error,
> > > please immediately reply to the sender and delete this information from
> > > your system. Use, dissemination, distribution, or reproduction of this
> > > transmission by unintended recipients is not authorized and may be
> > unlawful.
> > >
> >
>

Re: Plugins Release today

[Brian LeRoux]

thx Steve!


On Thu, Dec 5, 2013 at 2:47 PM, Steven Gill  wrote:

> Plugins have been released!
>
> http://cordova.apache.org/news/2013/12/04/plugins-release.html
> https://twitter.com/apachecordova/status/408441655222476800
>
> device-motion and battery-status haven't been published yet due to a error
> I ran into with plugman publish. I have pinged Anis to take a look. They
> will be up asap.
>
> File also didn't get released today. It will hopefully be ready to get
> released next week before 3.3.0 final!
>
> Cheers,
> -Steve
>
>
> On Wed, Dec 4, 2013 at 12:55 PM, Josh Soref  wrote:
>
> > > I suspect we almost always want to test new feature against tip-of-tree
> > > (I guess thats master).
> >
> > For what I believe are hysterical reasons, I think it's sometimes called
> > "dev".
> >
> > > So being able to run that but replace some of the
> > repos with a different branch would be awesome.
> >
> > > What if we used the convention of naming feature branches in all the
> > applicable repos the same thing,
> > > that way we can poke CI with a single name and it would check out that
> > branch on all the repos if it existed?
> > -
> > This transmission (including any attachments) may contain confidential
> > information, privileged material (including material protected by the
> > solicitor-client or other applicable privileges), or constitute
> non-public
> > information. Any use of this information by anyone other than the
> intended
> > recipient is prohibited. If you have received this transmission in error,
> > please immediately reply to the sender and delete this information from
> > your system. Use, dissemination, distribution, or reproduction of this
> > transmission by unintended recipients is not authorized and may be
> unlawful.
> >
>

Re: Plugins Release today

[Steven Gill]

Plugins have been released!

http://cordova.apache.org/news/2013/12/04/plugins-release.html
https://twitter.com/apachecordova/status/408441655222476800

device-motion and battery-status haven't been published yet due to a error
I ran into with plugman publish. I have pinged Anis to take a look. They
will be up asap.

File also didn't get released today. It will hopefully be ready to get
released next week before 3.3.0 final!

Cheers,
-Steve


On Wed, Dec 4, 2013 at 12:55 PM, Josh Soref  wrote:

> > I suspect we almost always want to test new feature against tip-of-tree
> > (I guess thats master).
>
> For what I believe are hysterical reasons, I think it's sometimes called
> "dev".
>
> > So being able to run that but replace some of the
> repos with a different branch would be awesome.
>
> > What if we used the convention of naming feature branches in all the
> applicable repos the same thing,
> > that way we can poke CI with a single name and it would check out that
> branch on all the repos if it existed?
> -
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>

Re: Plugins Release today

[Josh Soref]

> I suspect we almost always want to test new feature against tip-of-tree
> (I guess thats master). ‎

For what I believe are hysterical reasons, I think it's sometimes called "dev". 

> So being able to run that but replace some of the
repos with a different branch would be awesome. 

> What if we used the convention of naming feature branches in all the 
> applicable repos the same thing,
> that way we can poke CI with a single name and it would check out‎ that 
> branch on all the repos if it existed?
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Re: Plugins Release today

[Michal Mocny]

On Wed, Dec 4, 2013 at 2:54 PM, David Kemp  wrote:

> You can definitely do an automated build on demand, but the interesting
> part is specifying exactly what to build.
> Currently a build is made up of a bunch of repos at one tag, and some other
> repos at another tag.
> We would need to have a well defined way to specify which tag for each
> repo.
>
> example:
> I want to build cordova-android from the 'fancy-pants' branch, because I am
> ready to push it to master
>
> I presumably need:
>   cordova-android - fancy-pants branch
>   cli,plugman,coho,mobilespec, js from master branch
>   all plugins from master branch
>
> If we can ALWAYS say that a demand build is the same as a master build, but
> with one repo at a different branch that might be pretty easy...
>
+1 to this.

I suspect we almost always want to test new feature against tip-of-tree (I
guess thats master).  So being able to run that but replace some of the
repos with a different branch would be awesome.  What if we used the
convention of naming feature branches in all the applicable repos the same
thing, that way we can poke CI with a single name and it would check out
that branch on all the repos if it existed?


>
>
>
>
> On Wed, Dec 4, 2013 at 2:44 PM, Ian Clelland  wrote:
>
> > On Tue, Dec 3, 2013 at 3:29 PM, Steven Gill 
> > wrote:
> >
> > > On Tue, Dec 3, 2013 at 12:14 PM, Ian Clelland 
> > > wrote:> Dev becomes a staging branch, essentially; and all actual dev
> > work
> > > happens
> > >  > on branches. That sounds like a more sane way to do it. The only
> > reason
> > > I
> > > > had it on dev in the first place was to be able to test with buildbot
> > --
> > > > I'd love to have a way to run those branches through the CI server
> > before
> > > > merging them into dev/staging/master.
> > >
> > >
> > > Good point. Maybe we standardize a third branch (ducks for cover) that
> > the
> > > CI server also tests and can be used for breaking dev work. This way
> dev
> > is
> > > used for staging and only has code that can be released. I'm afraid
> that
> > > this just adds more complexity to plugins though and I am not a fan of
> > > adding more complexity.
> > >
> >
> > I was thinking that it would be cool to be able to force a buildbot build
> > of a specific branch (though maybe a set of branches would be required)
> --
> > it wouldn't have to happen with every commit, but you could say "I'm
> ready
> > to merge my feature into dev, let's get buildbot to run all of the tests
> on
> > that branch first, to see if the merge will break anything".
> >
> > That would avoid the need for a third special branch, but would let
> anybody
> > with access to buildbot (which we hope is everybody, soon) the ability to
> > test a branch before merging.
> >
> > I don't know if it's possible to get buildbot to do that or not; I'll
> defer
> > to David on that subject :)
> >
> > Ian
> >
> >
> > >
> > > >
> > >  Ian
> > > >
> > > >
> > > >
> > > > > Still confusing at times. It will be
> > > > > nice once we can get away from this dev-master setup we have. I'm
> > sure
> > > > many
> > > > > of us have pushed code to dev that isn't in a sate to be released.
> > > Maybe
> > > > > this point/process should get added to our wiki? Not sure where the
> > > best
> > > > > place for it would be.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Dec 3, 2013 at 11:34 AM, Ian Clelland <
> iclell...@google.com>
> > > > > wrote:
> > > > >
> > > > > > Hey Steven,
> > > > > >
> > > > > > File is close to being ready, but I haven't merged in my Android
> > code
> > > > > yet,
> > > > > > and I want to add some more tests, given how critical the plugin
> > is.
> > > > I'm
> > > > > > not comfortable with it going to master yet. If you want, I can
> > pull
> > > it
> > > > > out
> > > > > > of dev and put it on another branch. (There have been some other
> > > > commits,
> > > > > > so we could also create a new branch without those commits, and
> > merge
> > > > > > *that* into master instead)
> > > > > >
> > > > > > Let me know how you want to handle it, I'll help out any way I
> can.
> > > > > >
> > > > > > Ian
> > > > > >
> > > > > >
> > > > > > On Tue, Dec 3, 2013 at 2:20 PM, Steven Gill <
> > stevengil...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Any plugin issues I should know about before releasing today?
> > > > > > >
> > > > > > > Last I heard file and file-transfer dev branches aren't ready
> to
> > be
> > > > > > merged
> > > > > > > into master. Has this changed? Ian?
> > > > > > >
> > > > > > > Plugin issues that are still being reviewed/worked on:
> > > > > > > https://issues.apache.org/jira/browse/CB-5525
> > > > > > > https://issues.apache.org/jira/browse/CB-5531
> > > > > > > https://issues.apache.org/jira/browse/CB-5532
> > > > > > > https://issues.apache.org/jira/browse/CB-5430
> > > > > > > https://issues.apache.org/jira/browse/CB-5504
> > > > > > > https://issues.apache.org/jira/browse/CB-5505
> > > > > > >
> > > > > > > I can 

Re: Plugins Release today

[David Kemp]

You can definitely do an automated build on demand, but the interesting
part is specifying exactly what to build.
Currently a build is made up of a bunch of repos at one tag, and some other
repos at another tag.
We would need to have a well defined way to specify which tag for each repo.

example:
I want to build cordova-android from the 'fancy-pants' branch, because I am
ready to push it to master

I presumably need:
  cordova-android - fancy-pants branch
  cli,plugman,coho,mobilespec, js from master branch
  all plugins from master branch

If we can ALWAYS say that a demand build is the same as a master build, but
with one repo at a different branch that might be pretty easy...




On Wed, Dec 4, 2013 at 2:44 PM, Ian Clelland  wrote:

> On Tue, Dec 3, 2013 at 3:29 PM, Steven Gill 
> wrote:
>
> > On Tue, Dec 3, 2013 at 12:14 PM, Ian Clelland 
> > wrote:> Dev becomes a staging branch, essentially; and all actual dev
> work
> > happens
> >  > on branches. That sounds like a more sane way to do it. The only
> reason
> > I
> > > had it on dev in the first place was to be able to test with buildbot
> --
> > > I'd love to have a way to run those branches through the CI server
> before
> > > merging them into dev/staging/master.
> >
> >
> > Good point. Maybe we standardize a third branch (ducks for cover) that
> the
> > CI server also tests and can be used for breaking dev work. This way dev
> is
> > used for staging and only has code that can be released. I'm afraid that
> > this just adds more complexity to plugins though and I am not a fan of
> > adding more complexity.
> >
>
> I was thinking that it would be cool to be able to force a buildbot build
> of a specific branch (though maybe a set of branches would be required) --
> it wouldn't have to happen with every commit, but you could say "I'm ready
> to merge my feature into dev, let's get buildbot to run all of the tests on
> that branch first, to see if the merge will break anything".
>
> That would avoid the need for a third special branch, but would let anybody
> with access to buildbot (which we hope is everybody, soon) the ability to
> test a branch before merging.
>
> I don't know if it's possible to get buildbot to do that or not; I'll defer
> to David on that subject :)
>
> Ian
>
>
> >
> > >
> >  Ian
> > >
> > >
> > >
> > > > Still confusing at times. It will be
> > > > nice once we can get away from this dev-master setup we have. I'm
> sure
> > > many
> > > > of us have pushed code to dev that isn't in a sate to be released.
> > Maybe
> > > > this point/process should get added to our wiki? Not sure where the
> > best
> > > > place for it would be.
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Dec 3, 2013 at 11:34 AM, Ian Clelland 
> > > > wrote:
> > > >
> > > > > Hey Steven,
> > > > >
> > > > > File is close to being ready, but I haven't merged in my Android
> code
> > > > yet,
> > > > > and I want to add some more tests, given how critical the plugin
> is.
> > > I'm
> > > > > not comfortable with it going to master yet. If you want, I can
> pull
> > it
> > > > out
> > > > > of dev and put it on another branch. (There have been some other
> > > commits,
> > > > > so we could also create a new branch without those commits, and
> merge
> > > > > *that* into master instead)
> > > > >
> > > > > Let me know how you want to handle it, I'll help out any way I can.
> > > > >
> > > > > Ian
> > > > >
> > > > >
> > > > > On Tue, Dec 3, 2013 at 2:20 PM, Steven Gill <
> stevengil...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Any plugin issues I should know about before releasing today?
> > > > > >
> > > > > > Last I heard file and file-transfer dev branches aren't ready to
> be
> > > > > merged
> > > > > > into master. Has this changed? Ian?
> > > > > >
> > > > > > Plugin issues that are still being reviewed/worked on:
> > > > > > https://issues.apache.org/jira/browse/CB-5525
> > > > > > https://issues.apache.org/jira/browse/CB-5531
> > > > > > https://issues.apache.org/jira/browse/CB-5532
> > > > > > https://issues.apache.org/jira/browse/CB-5430
> > > > > > https://issues.apache.org/jira/browse/CB-5504
> > > > > > https://issues.apache.org/jira/browse/CB-5505
> > > > > >
> > > > > > I can wait until later in the day to release if some of these are
> > > > getting
> > > > > > resolve today. I know Jesse is looking at the windows ones.
> > > > > >
> > > > > > We can also just do another plugin release next week (or post
> > > holidays)
> > > > > > once some of these land.
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Plugins Release today

[Ian Clelland]

On Tue, Dec 3, 2013 at 3:29 PM, Steven Gill  wrote:

> On Tue, Dec 3, 2013 at 12:14 PM, Ian Clelland 
> wrote:> Dev becomes a staging branch, essentially; and all actual dev work
> happens
>  > on branches. That sounds like a more sane way to do it. The only reason
> I
> > had it on dev in the first place was to be able to test with buildbot --
> > I'd love to have a way to run those branches through the CI server before
> > merging them into dev/staging/master.
>
>
> Good point. Maybe we standardize a third branch (ducks for cover) that the
> CI server also tests and can be used for breaking dev work. This way dev is
> used for staging and only has code that can be released. I'm afraid that
> this just adds more complexity to plugins though and I am not a fan of
> adding more complexity.
>

I was thinking that it would be cool to be able to force a buildbot build
of a specific branch (though maybe a set of branches would be required) --
it wouldn't have to happen with every commit, but you could say "I'm ready
to merge my feature into dev, let's get buildbot to run all of the tests on
that branch first, to see if the merge will break anything".

That would avoid the need for a third special branch, but would let anybody
with access to buildbot (which we hope is everybody, soon) the ability to
test a branch before merging.

I don't know if it's possible to get buildbot to do that or not; I'll defer
to David on that subject :)

Ian


>
> >
>  Ian
> >
> >
> >
> > > Still confusing at times. It will be
> > > nice once we can get away from this dev-master setup we have. I'm sure
> > many
> > > of us have pushed code to dev that isn't in a sate to be released.
> Maybe
> > > this point/process should get added to our wiki? Not sure where the
> best
> > > place for it would be.
> > >
> > >
> > >
> > >
> > > On Tue, Dec 3, 2013 at 11:34 AM, Ian Clelland 
> > > wrote:
> > >
> > > > Hey Steven,
> > > >
> > > > File is close to being ready, but I haven't merged in my Android code
> > > yet,
> > > > and I want to add some more tests, given how critical the plugin is.
> > I'm
> > > > not comfortable with it going to master yet. If you want, I can pull
> it
> > > out
> > > > of dev and put it on another branch. (There have been some other
> > commits,
> > > > so we could also create a new branch without those commits, and merge
> > > > *that* into master instead)
> > > >
> > > > Let me know how you want to handle it, I'll help out any way I can.
> > > >
> > > > Ian
> > > >
> > > >
> > > > On Tue, Dec 3, 2013 at 2:20 PM, Steven Gill 
> > > > wrote:
> > > >
> > > > > Any plugin issues I should know about before releasing today?
> > > > >
> > > > > Last I heard file and file-transfer dev branches aren't ready to be
> > > > merged
> > > > > into master. Has this changed? Ian?
> > > > >
> > > > > Plugin issues that are still being reviewed/worked on:
> > > > > https://issues.apache.org/jira/browse/CB-5525
> > > > > https://issues.apache.org/jira/browse/CB-5531
> > > > > https://issues.apache.org/jira/browse/CB-5532
> > > > > https://issues.apache.org/jira/browse/CB-5430
> > > > > https://issues.apache.org/jira/browse/CB-5504
> > > > > https://issues.apache.org/jira/browse/CB-5505
> > > > >
> > > > > I can wait until later in the day to release if some of these are
> > > getting
> > > > > resolve today. I know Jesse is looking at the windows ones.
> > > > >
> > > > > We can also just do another plugin release next week (or post
> > holidays)
> > > > > once some of these land.
> > > > >
> > > >
> > >
> >
>

Re: Plugins Release today

[Steven Gill]

On Tue, Dec 3, 2013 at 12:14 PM, Ian Clelland  wrote:

> On Tue, Dec 3, 2013 at 3:00 PM, Steven Gill 
> wrote:
>
> > Thanks for filling me in on the state!
> >
> > Is it just File that isn't ready? File-transfer is good?
> >
>
> I'll see if I can run a test on iOS with the dev branch of file-transfer,
> and the master branch of file -- if that still passes, I'll OK releasing
> file-transfer. (If not, I'll fix it until it does :) )
>
> Sounds good!

>
> > I don't think it is worth it to rip out the code from dev, especially if
> it
> > is almost ready. I will hold off releasing file with this plugins
> release.
> > We can aim to get a new version of file out next week after it has been
> > tested (especially with plugins that depend on it). Of course, if you
> > strongly feel some of those other commits on file should get out asap,
> then
> > lets move forward with ripping out so it can be released.
> >
> > In the future we should all try to work off branches and push code onto
> dev
> > that is ready to be pushed to master. We should use dev as master since
> our
> > master branch is just for releasing.
>
>
> Dev becomes a staging branch, essentially; and all actual dev work happens
> on branches. That sounds like a more sane way to do it. The only reason I
> had it on dev in the first place was to be able to test with buildbot --
> I'd love to have a way to run those branches through the CI server before
> merging them into dev/staging/master.


Good point. Maybe we standardize a third branch (ducks for cover) that the
CI server also tests and can be used for breaking dev work. This way dev is
used for staging and only has code that can be released. I'm afraid that
this just adds more complexity to plugins though and I am not a fan of
adding more complexity.


>
 Ian
>
>
>
> > Still confusing at times. It will be
> > nice once we can get away from this dev-master setup we have. I'm sure
> many
> > of us have pushed code to dev that isn't in a sate to be released. Maybe
> > this point/process should get added to our wiki? Not sure where the best
> > place for it would be.
> >
> >
> >
> >
> > On Tue, Dec 3, 2013 at 11:34 AM, Ian Clelland 
> > wrote:
> >
> > > Hey Steven,
> > >
> > > File is close to being ready, but I haven't merged in my Android code
> > yet,
> > > and I want to add some more tests, given how critical the plugin is.
> I'm
> > > not comfortable with it going to master yet. If you want, I can pull it
> > out
> > > of dev and put it on another branch. (There have been some other
> commits,
> > > so we could also create a new branch without those commits, and merge
> > > *that* into master instead)
> > >
> > > Let me know how you want to handle it, I'll help out any way I can.
> > >
> > > Ian
> > >
> > >
> > > On Tue, Dec 3, 2013 at 2:20 PM, Steven Gill 
> > > wrote:
> > >
> > > > Any plugin issues I should know about before releasing today?
> > > >
> > > > Last I heard file and file-transfer dev branches aren't ready to be
> > > merged
> > > > into master. Has this changed? Ian?
> > > >
> > > > Plugin issues that are still being reviewed/worked on:
> > > > https://issues.apache.org/jira/browse/CB-5525
> > > > https://issues.apache.org/jira/browse/CB-5531
> > > > https://issues.apache.org/jira/browse/CB-5532
> > > > https://issues.apache.org/jira/browse/CB-5430
> > > > https://issues.apache.org/jira/browse/CB-5504
> > > > https://issues.apache.org/jira/browse/CB-5505
> > > >
> > > > I can wait until later in the day to release if some of these are
> > getting
> > > > resolve today. I know Jesse is looking at the windows ones.
> > > >
> > > > We can also just do another plugin release next week (or post
> holidays)
> > > > once some of these land.
> > > >
> > >
> >
>

Re: Plugins Release today

[Ian Clelland]

On Tue, Dec 3, 2013 at 3:00 PM, Steven Gill  wrote:

> Thanks for filling me in on the state!
>
> Is it just File that isn't ready? File-transfer is good?
>

I'll see if I can run a test on iOS with the dev branch of file-transfer,
and the master branch of file -- if that still passes, I'll OK releasing
file-transfer. (If not, I'll fix it until it does :) )


> I don't think it is worth it to rip out the code from dev, especially if it
> is almost ready. I will hold off releasing file with this plugins release.
> We can aim to get a new version of file out next week after it has been
> tested (especially with plugins that depend on it). Of course, if you
> strongly feel some of those other commits on file should get out asap, then
> lets move forward with ripping out so it can be released.
>
> In the future we should all try to work off branches and push code onto dev
> that is ready to be pushed to master. We should use dev as master since our
> master branch is just for releasing.


Dev becomes a staging branch, essentially; and all actual dev work happens
on branches. That sounds like a more sane way to do it. The only reason I
had it on dev in the first place was to be able to test with buildbot --
I'd love to have a way to run those branches through the CI server before
merging them into dev/staging/master.


Ian



> Still confusing at times. It will be
> nice once we can get away from this dev-master setup we have. I'm sure many
> of us have pushed code to dev that isn't in a sate to be released. Maybe
> this point/process should get added to our wiki? Not sure where the best
> place for it would be.
>
>
>
>
> On Tue, Dec 3, 2013 at 11:34 AM, Ian Clelland 
> wrote:
>
> > Hey Steven,
> >
> > File is close to being ready, but I haven't merged in my Android code
> yet,
> > and I want to add some more tests, given how critical the plugin is. I'm
> > not comfortable with it going to master yet. If you want, I can pull it
> out
> > of dev and put it on another branch. (There have been some other commits,
> > so we could also create a new branch without those commits, and merge
> > *that* into master instead)
> >
> > Let me know how you want to handle it, I'll help out any way I can.
> >
> > Ian
> >
> >
> > On Tue, Dec 3, 2013 at 2:20 PM, Steven Gill 
> > wrote:
> >
> > > Any plugin issues I should know about before releasing today?
> > >
> > > Last I heard file and file-transfer dev branches aren't ready to be
> > merged
> > > into master. Has this changed? Ian?
> > >
> > > Plugin issues that are still being reviewed/worked on:
> > > https://issues.apache.org/jira/browse/CB-5525
> > > https://issues.apache.org/jira/browse/CB-5531
> > > https://issues.apache.org/jira/browse/CB-5532
> > > https://issues.apache.org/jira/browse/CB-5430
> > > https://issues.apache.org/jira/browse/CB-5504
> > > https://issues.apache.org/jira/browse/CB-5505
> > >
> > > I can wait until later in the day to release if some of these are
> getting
> > > resolve today. I know Jesse is looking at the windows ones.
> > >
> > > We can also just do another plugin release next week (or post holidays)
> > > once some of these land.
> > >
> >
>

Re: Plugins Release today

[Steven Gill]

Thanks for filling me in on the state!

Is it just File that isn't ready? File-transfer is good?

I don't think it is worth it to rip out the code from dev, especially if it
is almost ready. I will hold off releasing file with this plugins release.
We can aim to get a new version of file out next week after it has been
tested (especially with plugins that depend on it). Of course, if you
strongly feel some of those other commits on file should get out asap, then
lets move forward with ripping out so it can be released.

In the future we should all try to work off branches and push code onto dev
that is ready to be pushed to master. We should use dev as master since our
master branch is just for releasing. Still confusing at times. It will be
nice once we can get away from this dev-master setup we have. I'm sure many
of us have pushed code to dev that isn't in a sate to be released. Maybe
this point/process should get added to our wiki? Not sure where the best
place for it would be.




On Tue, Dec 3, 2013 at 11:34 AM, Ian Clelland  wrote:

> Hey Steven,
>
> File is close to being ready, but I haven't merged in my Android code yet,
> and I want to add some more tests, given how critical the plugin is. I'm
> not comfortable with it going to master yet. If you want, I can pull it out
> of dev and put it on another branch. (There have been some other commits,
> so we could also create a new branch without those commits, and merge
> *that* into master instead)
>
> Let me know how you want to handle it, I'll help out any way I can.
>
> Ian
>
>
> On Tue, Dec 3, 2013 at 2:20 PM, Steven Gill 
> wrote:
>
> > Any plugin issues I should know about before releasing today?
> >
> > Last I heard file and file-transfer dev branches aren't ready to be
> merged
> > into master. Has this changed? Ian?
> >
> > Plugin issues that are still being reviewed/worked on:
> > https://issues.apache.org/jira/browse/CB-5525
> > https://issues.apache.org/jira/browse/CB-5531
> > https://issues.apache.org/jira/browse/CB-5532
> > https://issues.apache.org/jira/browse/CB-5430
> > https://issues.apache.org/jira/browse/CB-5504
> > https://issues.apache.org/jira/browse/CB-5505
> >
> > I can wait until later in the day to release if some of these are getting
> > resolve today. I know Jesse is looking at the windows ones.
> >
> > We can also just do another plugin release next week (or post holidays)
> > once some of these land.
> >
>

Re: Plugins Release today

[Ian Clelland]

Hey Steven,

File is close to being ready, but I haven't merged in my Android code yet,
and I want to add some more tests, given how critical the plugin is. I'm
not comfortable with it going to master yet. If you want, I can pull it out
of dev and put it on another branch. (There have been some other commits,
so we could also create a new branch without those commits, and merge
*that* into master instead)

Let me know how you want to handle it, I'll help out any way I can.

Ian


On Tue, Dec 3, 2013 at 2:20 PM, Steven Gill  wrote:

> Any plugin issues I should know about before releasing today?
>
> Last I heard file and file-transfer dev branches aren't ready to be merged
> into master. Has this changed? Ian?
>
> Plugin issues that are still being reviewed/worked on:
> https://issues.apache.org/jira/browse/CB-5525
> https://issues.apache.org/jira/browse/CB-5531
> https://issues.apache.org/jira/browse/CB-5532
> https://issues.apache.org/jira/browse/CB-5430
> https://issues.apache.org/jira/browse/CB-5504
> https://issues.apache.org/jira/browse/CB-5505
>
> I can wait until later in the day to release if some of these are getting
> resolve today. I know Jesse is looking at the windows ones.
>
> We can also just do another plugin release next week (or post holidays)
> once some of these land.
>

Re: Plugins Release

[Viras]

Just as a side note:

this release should also fix file-transfer on WP7 & WP8 => 
https://issues.apache.org/jira/browse/CB-4668 & 
https://issues.apache.org/jira/browse/CB-4717


Best,
Wolfgang

Am 2013-10-11 01:25, schrieb Steven Gill:

Plugins have been released for this week.
http://cordova.apache.org/news/2013/10/10/plugins-release.html


On Wed, Oct 9, 2013 at 1:34 PM, Andrew Grieve  
wrote:



Btw - sounds good about plugin release!

No need to add the labs plugins (as you said, they are already 
there), but
it would be good to mention them in your blog post (just the 
published

ones: keyboard, websql, statusbar).


On Wed, Oct 9, 2013 at 4:32 PM, Andrew Grieve 
wrote:


An alternative to new repos for all of them is to put them in their
platform repos. So far none of them have multiple platforms.

I'd like to wait a while before creating too many more plugin
repositories, just until the number of plugins levels out.


On Wed, Oct 9, 2013 at 3:32 PM, Steven Gill So plugins that are on cordova-labs will not be included in my 
release

this
week.

It seems like people have been publishing the cordova-labs plugins
independently so far from the (bi)-weekly plugins release.

Plugins in cordova-labs include:
keyboard (published to registry)
websql (published to registry)
statusbar (published to registry)
file-extras
android storage

I propose that these plugins (especially the top 3) get moved into 
repos

of
their own and join the plugin release train starting with the next
release.
This way we prevent the plugins branch from becoming another case 
of

https://github.com/phonegap/phonegap-plugins

Thoughts?

-Steve


On Wed, Oct 9, 2013 at 11:24 AM, Steven Gill 


wrote:


I am about to initiate the process for doing this release today.

This will include generating release notes + updating versions for 
the
plugins that have changes since the last release. I will then 
publish

them

to the registry and whip up a blog post.

I heard we have more plugins on cordova-labs that could benefit 
from

being
included in this plugins release process. I would love for people 
to

let me
know on this thread what plugins I should be looking at other than 
our

core

ones.




On Mon, Oct 7, 2013 at 12:37 PM, Steven Gill 

wrote:


https://issues.apache.org/jira/browse/CB-5010


On Mon, Oct 7, 2013 at 3:24 PM, Steven Gill 

wrote:



If we want to do CLI/Plugman, we definitely will need to do more

testing
and fix some things (like FFOS). I think we also need to make 
sure

that
some of the changes that went into cordova-3.1.x branches also 
ended

up in

the refactored master branches.

I will plan on doing the plugins release tomorrow/Wednesday.

Steve


On Mon, Oct 7, 2013 at 3:16 PM, Andrew Grieve 

wrote:



I remember someone said the refactoring broke ffos. Not sure if

that's

fixed yet?

Other than that, sounds great to release both this week. Would 
be

good

to
do them together so as to have a shared blog post.


On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson <

bra...@chromium.org

wrote:



Er, I didn't actually say: for the tools, not yet, maybe later

this

week.


Braden


On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson <

bra...@chromium.org

wrote:



I'll want to have a hand in the next release of the tools,

because

of the

refactoring.

Braden


On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill <

stevengil...@gmail.com

wrote:


Last week as we were finishing off the release, I remember

their

was

some

interest in doing another plugins release this week.

I know windows 8 file transfer needs to be updated and Shaz

has

some iOS

releated plugin changes that could be updated as well.

Any resistance to me kicking this off and aiming to get out 
a

plugins

release tomorrow/wed?

We can also do CLI/Plugman releases on a weekly basis. If

anyone

has a
reason to update one of these, let me know and we can kick 
up

a

separate

thread.

I feel like I got a pretty solid understanding of our 
various

release

processes over that last two weeks.

-Steve
























--
GOFG - Get On Fat Guy
http://www.gofg.at/ - powered by Cordova

Re: Plugins Release

[Steven Gill]

Plugins have been released for this week.
http://cordova.apache.org/news/2013/10/10/plugins-release.html


On Wed, Oct 9, 2013 at 1:34 PM, Andrew Grieve  wrote:

> Btw - sounds good about plugin release!
>
> No need to add the labs plugins (as you said, they are already there), but
> it would be good to mention them in your blog post (just the published
> ones: keyboard, websql, statusbar).
>
>
> On Wed, Oct 9, 2013 at 4:32 PM, Andrew Grieve 
> wrote:
>
> > An alternative to new repos for all of them is to put them in their
> > platform repos. So far none of them have multiple platforms.
> >
> > I'd like to wait a while before creating too many more plugin
> > repositories, just until the number of plugins levels out.
> >
> >
> > On Wed, Oct 9, 2013 at 3:32 PM, Steven Gill  >wrote:
> >
> >> So plugins that are on cordova-labs will not be included in my release
> >> this
> >> week.
> >>
> >> It seems like people have been publishing the cordova-labs plugins
> >> independently so far from the (bi)-weekly plugins release.
> >>
> >> Plugins in cordova-labs include:
> >> keyboard (published to registry)
> >> websql (published to registry)
> >> statusbar (published to registry)
> >> file-extras
> >> android storage
> >>
> >> I propose that these plugins (especially the top 3) get moved into repos
> >> of
> >> their own and join the plugin release train starting with the next
> >> release.
> >> This way we prevent the plugins branch from becoming another case of
> >> https://github.com/phonegap/phonegap-plugins
> >>
> >> Thoughts?
> >>
> >> -Steve
> >>
> >>
> >> On Wed, Oct 9, 2013 at 11:24 AM, Steven Gill 
> >> wrote:
> >>
> >> > I am about to initiate the process for doing this release today.
> >> >
> >> > This will include generating release notes + updating versions for the
> >> > plugins that have changes since the last release. I will then publish
> >> them
> >> > to the registry and whip up a blog post.
> >> >
> >> > I heard we have more plugins on cordova-labs that could benefit from
> >> being
> >> > included in this plugins release process. I would love for people to
> >> let me
> >> > know on this thread what plugins I should be looking at other than our
> >> core
> >> > ones.
> >> >
> >> >
> >> >
> >> >
> >> > On Mon, Oct 7, 2013 at 12:37 PM, Steven Gill  >> >wrote:
> >> >
> >> >> https://issues.apache.org/jira/browse/CB-5010
> >> >>
> >> >>
> >> >> On Mon, Oct 7, 2013 at 3:24 PM, Steven Gill  >> >wrote:
> >> >>
> >> >>> If we want to do CLI/Plugman, we definitely will need to do more
> >> testing
> >> >>> and fix some things (like FFOS). I think we also need to make sure
> >> that
> >> >>> some of the changes that went into cordova-3.1.x branches also ended
> >> up in
> >> >>> the refactored master branches.
> >> >>>
> >> >>> I will plan on doing the plugins release tomorrow/Wednesday.
> >> >>>
> >> >>> Steve
> >> >>>
> >> >>>
> >> >>> On Mon, Oct 7, 2013 at 3:16 PM, Andrew Grieve  >> >wrote:
> >> >>>
> >>  I remember someone said the refactoring broke ffos. Not sure if
> >> that's
> >>  fixed yet?
> >> 
> >>  Other than that, sounds great to release both this week. Would be
> >> good
> >>  to
> >>  do them together so as to have a shared blog post.
> >> 
> >> 
> >>  On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson <
> >> bra...@chromium.org
> >>  >wrote:
> >> 
> >>  > Er, I didn't actually say: for the tools, not yet, maybe later
> this
> >>  week.
> >>  >
> >>  > Braden
> >>  >
> >>  >
> >>  > On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson <
> >>  bra...@chromium.org
> >>  > >wrote:
> >>  >
> >>  > > I'll want to have a hand in the next release of the tools,
> >> because
> >>  of the
> >>  > > refactoring.
> >>  > >
> >>  > > Braden
> >>  > >
> >>  > >
> >>  > > On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill <
> >> stevengil...@gmail.com
> >>  > >wrote:
> >>  > >
> >>  > >> Last week as we were finishing off the release, I remember
> their
> >>  was
> >>  > some
> >>  > >> interest in doing another plugins release this week.
> >>  > >>
> >>  > >> I know windows 8 file transfer needs to be updated and Shaz
> has
> >>  some iOS
> >>  > >> releated plugin changes that could be updated as well.
> >>  > >>
> >>  > >> Any resistance to me kicking this off and aiming to get out a
> >>  plugins
> >>  > >> release tomorrow/wed?
> >>  > >>
> >>  > >> We can also do CLI/Plugman releases on a weekly basis. If
> anyone
> >>  has a
> >>  > >> reason to update one of these, let me know and we can kick up
> a
> >>  separate
> >>  > >> thread.
> >>  > >>
> >>  > >> I feel like I got a pretty solid understanding of our various
> >>  release
> >>  > >> processes over that last two weeks.
> >>  > >>
> >>  > >> -Steve
> >>  > >>
> >>  > >
> >>  > >
> >>  >
> >> 
> >> >>>
> >> >>>

Re: Plugins Release

[Andrew Grieve]

Btw - sounds good about plugin release!

No need to add the labs plugins (as you said, they are already there), but
it would be good to mention them in your blog post (just the published
ones: keyboard, websql, statusbar).


On Wed, Oct 9, 2013 at 4:32 PM, Andrew Grieve  wrote:

> An alternative to new repos for all of them is to put them in their
> platform repos. So far none of them have multiple platforms.
>
> I'd like to wait a while before creating too many more plugin
> repositories, just until the number of plugins levels out.
>
>
> On Wed, Oct 9, 2013 at 3:32 PM, Steven Gill wrote:
>
>> So plugins that are on cordova-labs will not be included in my release
>> this
>> week.
>>
>> It seems like people have been publishing the cordova-labs plugins
>> independently so far from the (bi)-weekly plugins release.
>>
>> Plugins in cordova-labs include:
>> keyboard (published to registry)
>> websql (published to registry)
>> statusbar (published to registry)
>> file-extras
>> android storage
>>
>> I propose that these plugins (especially the top 3) get moved into repos
>> of
>> their own and join the plugin release train starting with the next
>> release.
>> This way we prevent the plugins branch from becoming another case of
>> https://github.com/phonegap/phonegap-plugins
>>
>> Thoughts?
>>
>> -Steve
>>
>>
>> On Wed, Oct 9, 2013 at 11:24 AM, Steven Gill 
>> wrote:
>>
>> > I am about to initiate the process for doing this release today.
>> >
>> > This will include generating release notes + updating versions for the
>> > plugins that have changes since the last release. I will then publish
>> them
>> > to the registry and whip up a blog post.
>> >
>> > I heard we have more plugins on cordova-labs that could benefit from
>> being
>> > included in this plugins release process. I would love for people to
>> let me
>> > know on this thread what plugins I should be looking at other than our
>> core
>> > ones.
>> >
>> >
>> >
>> >
>> > On Mon, Oct 7, 2013 at 12:37 PM, Steven Gill > >wrote:
>> >
>> >> https://issues.apache.org/jira/browse/CB-5010
>> >>
>> >>
>> >> On Mon, Oct 7, 2013 at 3:24 PM, Steven Gill > >wrote:
>> >>
>> >>> If we want to do CLI/Plugman, we definitely will need to do more
>> testing
>> >>> and fix some things (like FFOS). I think we also need to make sure
>> that
>> >>> some of the changes that went into cordova-3.1.x branches also ended
>> up in
>> >>> the refactored master branches.
>> >>>
>> >>> I will plan on doing the plugins release tomorrow/Wednesday.
>> >>>
>> >>> Steve
>> >>>
>> >>>
>> >>> On Mon, Oct 7, 2013 at 3:16 PM, Andrew Grieve > >wrote:
>> >>>
>>  I remember someone said the refactoring broke ffos. Not sure if
>> that's
>>  fixed yet?
>> 
>>  Other than that, sounds great to release both this week. Would be
>> good
>>  to
>>  do them together so as to have a shared blog post.
>> 
>> 
>>  On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson <
>> bra...@chromium.org
>>  >wrote:
>> 
>>  > Er, I didn't actually say: for the tools, not yet, maybe later this
>>  week.
>>  >
>>  > Braden
>>  >
>>  >
>>  > On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson <
>>  bra...@chromium.org
>>  > >wrote:
>>  >
>>  > > I'll want to have a hand in the next release of the tools,
>> because
>>  of the
>>  > > refactoring.
>>  > >
>>  > > Braden
>>  > >
>>  > >
>>  > > On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill <
>> stevengil...@gmail.com
>>  > >wrote:
>>  > >
>>  > >> Last week as we were finishing off the release, I remember their
>>  was
>>  > some
>>  > >> interest in doing another plugins release this week.
>>  > >>
>>  > >> I know windows 8 file transfer needs to be updated and Shaz has
>>  some iOS
>>  > >> releated plugin changes that could be updated as well.
>>  > >>
>>  > >> Any resistance to me kicking this off and aiming to get out a
>>  plugins
>>  > >> release tomorrow/wed?
>>  > >>
>>  > >> We can also do CLI/Plugman releases on a weekly basis. If anyone
>>  has a
>>  > >> reason to update one of these, let me know and we can kick up a
>>  separate
>>  > >> thread.
>>  > >>
>>  > >> I feel like I got a pretty solid understanding of our various
>>  release
>>  > >> processes over that last two weeks.
>>  > >>
>>  > >> -Steve
>>  > >>
>>  > >
>>  > >
>>  >
>> 
>> >>>
>> >>>
>> >>
>> >
>>
>
>

Re: Plugins Release

[Andrew Grieve]

An alternative to new repos for all of them is to put them in their
platform repos. So far none of them have multiple platforms.

I'd like to wait a while before creating too many more plugin repositories,
just until the number of plugins levels out.


On Wed, Oct 9, 2013 at 3:32 PM, Steven Gill  wrote:

> So plugins that are on cordova-labs will not be included in my release this
> week.
>
> It seems like people have been publishing the cordova-labs plugins
> independently so far from the (bi)-weekly plugins release.
>
> Plugins in cordova-labs include:
> keyboard (published to registry)
> websql (published to registry)
> statusbar (published to registry)
> file-extras
> android storage
>
> I propose that these plugins (especially the top 3) get moved into repos of
> their own and join the plugin release train starting with the next release.
> This way we prevent the plugins branch from becoming another case of
> https://github.com/phonegap/phonegap-plugins
>
> Thoughts?
>
> -Steve
>
>
> On Wed, Oct 9, 2013 at 11:24 AM, Steven Gill 
> wrote:
>
> > I am about to initiate the process for doing this release today.
> >
> > This will include generating release notes + updating versions for the
> > plugins that have changes since the last release. I will then publish
> them
> > to the registry and whip up a blog post.
> >
> > I heard we have more plugins on cordova-labs that could benefit from
> being
> > included in this plugins release process. I would love for people to let
> me
> > know on this thread what plugins I should be looking at other than our
> core
> > ones.
> >
> >
> >
> >
> > On Mon, Oct 7, 2013 at 12:37 PM, Steven Gill  >wrote:
> >
> >> https://issues.apache.org/jira/browse/CB-5010
> >>
> >>
> >> On Mon, Oct 7, 2013 at 3:24 PM, Steven Gill  >wrote:
> >>
> >>> If we want to do CLI/Plugman, we definitely will need to do more
> testing
> >>> and fix some things (like FFOS). I think we also need to make sure that
> >>> some of the changes that went into cordova-3.1.x branches also ended
> up in
> >>> the refactored master branches.
> >>>
> >>> I will plan on doing the plugins release tomorrow/Wednesday.
> >>>
> >>> Steve
> >>>
> >>>
> >>> On Mon, Oct 7, 2013 at 3:16 PM, Andrew Grieve  >wrote:
> >>>
>  I remember someone said the refactoring broke ffos. Not sure if that's
>  fixed yet?
> 
>  Other than that, sounds great to release both this week. Would be good
>  to
>  do them together so as to have a shared blog post.
> 
> 
>  On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson <
> bra...@chromium.org
>  >wrote:
> 
>  > Er, I didn't actually say: for the tools, not yet, maybe later this
>  week.
>  >
>  > Braden
>  >
>  >
>  > On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson <
>  bra...@chromium.org
>  > >wrote:
>  >
>  > > I'll want to have a hand in the next release of the tools, because
>  of the
>  > > refactoring.
>  > >
>  > > Braden
>  > >
>  > >
>  > > On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill <
> stevengil...@gmail.com
>  > >wrote:
>  > >
>  > >> Last week as we were finishing off the release, I remember their
>  was
>  > some
>  > >> interest in doing another plugins release this week.
>  > >>
>  > >> I know windows 8 file transfer needs to be updated and Shaz has
>  some iOS
>  > >> releated plugin changes that could be updated as well.
>  > >>
>  > >> Any resistance to me kicking this off and aiming to get out a
>  plugins
>  > >> release tomorrow/wed?
>  > >>
>  > >> We can also do CLI/Plugman releases on a weekly basis. If anyone
>  has a
>  > >> reason to update one of these, let me know and we can kick up a
>  separate
>  > >> thread.
>  > >>
>  > >> I feel like I got a pretty solid understanding of our various
>  release
>  > >> processes over that last two weeks.
>  > >>
>  > >> -Steve
>  > >>
>  > >
>  > >
>  >
> 
> >>>
> >>>
> >>
> >
>

Re: Plugins Release

[Steven Gill]

So plugins that are on cordova-labs will not be included in my release this
week.

It seems like people have been publishing the cordova-labs plugins
independently so far from the (bi)-weekly plugins release.

Plugins in cordova-labs include:
keyboard (published to registry)
websql (published to registry)
statusbar (published to registry)
file-extras
android storage

I propose that these plugins (especially the top 3) get moved into repos of
their own and join the plugin release train starting with the next release.
This way we prevent the plugins branch from becoming another case of
https://github.com/phonegap/phonegap-plugins

Thoughts?

-Steve


On Wed, Oct 9, 2013 at 11:24 AM, Steven Gill  wrote:

> I am about to initiate the process for doing this release today.
>
> This will include generating release notes + updating versions for the
> plugins that have changes since the last release. I will then publish them
> to the registry and whip up a blog post.
>
> I heard we have more plugins on cordova-labs that could benefit from being
> included in this plugins release process. I would love for people to let me
> know on this thread what plugins I should be looking at other than our core
> ones.
>
>
>
>
> On Mon, Oct 7, 2013 at 12:37 PM, Steven Gill wrote:
>
>> https://issues.apache.org/jira/browse/CB-5010
>>
>>
>> On Mon, Oct 7, 2013 at 3:24 PM, Steven Gill wrote:
>>
>>> If we want to do CLI/Plugman, we definitely will need to do more testing
>>> and fix some things (like FFOS). I think we also need to make sure that
>>> some of the changes that went into cordova-3.1.x branches also ended up in
>>> the refactored master branches.
>>>
>>> I will plan on doing the plugins release tomorrow/Wednesday.
>>>
>>> Steve
>>>
>>>
>>> On Mon, Oct 7, 2013 at 3:16 PM, Andrew Grieve wrote:
>>>
 I remember someone said the refactoring broke ffos. Not sure if that's
 fixed yet?

 Other than that, sounds great to release both this week. Would be good
 to
 do them together so as to have a shared blog post.


 On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson >>> >wrote:

 > Er, I didn't actually say: for the tools, not yet, maybe later this
 week.
 >
 > Braden
 >
 >
 > On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson <
 bra...@chromium.org
 > >wrote:
 >
 > > I'll want to have a hand in the next release of the tools, because
 of the
 > > refactoring.
 > >
 > > Braden
 > >
 > >
 > > On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill >>> > >wrote:
 > >
 > >> Last week as we were finishing off the release, I remember their
 was
 > some
 > >> interest in doing another plugins release this week.
 > >>
 > >> I know windows 8 file transfer needs to be updated and Shaz has
 some iOS
 > >> releated plugin changes that could be updated as well.
 > >>
 > >> Any resistance to me kicking this off and aiming to get out a
 plugins
 > >> release tomorrow/wed?
 > >>
 > >> We can also do CLI/Plugman releases on a weekly basis. If anyone
 has a
 > >> reason to update one of these, let me know and we can kick up a
 separate
 > >> thread.
 > >>
 > >> I feel like I got a pretty solid understanding of our various
 release
 > >> processes over that last two weeks.
 > >>
 > >> -Steve
 > >>
 > >
 > >
 >

>>>
>>>
>>
>

Re: Plugins Release

[Steven Gill]

I am about to initiate the process for doing this release today.

This will include generating release notes + updating versions for the
plugins that have changes since the last release. I will then publish them
to the registry and whip up a blog post.

I heard we have more plugins on cordova-labs that could benefit from being
included in this plugins release process. I would love for people to let me
know on this thread what plugins I should be looking at other than our core
ones.




On Mon, Oct 7, 2013 at 12:37 PM, Steven Gill  wrote:

> https://issues.apache.org/jira/browse/CB-5010
>
>
> On Mon, Oct 7, 2013 at 3:24 PM, Steven Gill wrote:
>
>> If we want to do CLI/Plugman, we definitely will need to do more testing
>> and fix some things (like FFOS). I think we also need to make sure that
>> some of the changes that went into cordova-3.1.x branches also ended up in
>> the refactored master branches.
>>
>> I will plan on doing the plugins release tomorrow/Wednesday.
>>
>> Steve
>>
>>
>> On Mon, Oct 7, 2013 at 3:16 PM, Andrew Grieve wrote:
>>
>>> I remember someone said the refactoring broke ffos. Not sure if that's
>>> fixed yet?
>>>
>>> Other than that, sounds great to release both this week. Would be good to
>>> do them together so as to have a shared blog post.
>>>
>>>
>>> On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson >> >wrote:
>>>
>>> > Er, I didn't actually say: for the tools, not yet, maybe later this
>>> week.
>>> >
>>> > Braden
>>> >
>>> >
>>> > On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson <
>>> bra...@chromium.org
>>> > >wrote:
>>> >
>>> > > I'll want to have a hand in the next release of the tools, because
>>> of the
>>> > > refactoring.
>>> > >
>>> > > Braden
>>> > >
>>> > >
>>> > > On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill >> > >wrote:
>>> > >
>>> > >> Last week as we were finishing off the release, I remember their was
>>> > some
>>> > >> interest in doing another plugins release this week.
>>> > >>
>>> > >> I know windows 8 file transfer needs to be updated and Shaz has
>>> some iOS
>>> > >> releated plugin changes that could be updated as well.
>>> > >>
>>> > >> Any resistance to me kicking this off and aiming to get out a
>>> plugins
>>> > >> release tomorrow/wed?
>>> > >>
>>> > >> We can also do CLI/Plugman releases on a weekly basis. If anyone
>>> has a
>>> > >> reason to update one of these, let me know and we can kick up a
>>> separate
>>> > >> thread.
>>> > >>
>>> > >> I feel like I got a pretty solid understanding of our various
>>> release
>>> > >> processes over that last two weeks.
>>> > >>
>>> > >> -Steve
>>> > >>
>>> > >
>>> > >
>>> >
>>>
>>
>>
>

Re: Plugins Release

[Steven Gill]

https://issues.apache.org/jira/browse/CB-5010


On Mon, Oct 7, 2013 at 3:24 PM, Steven Gill  wrote:

> If we want to do CLI/Plugman, we definitely will need to do more testing
> and fix some things (like FFOS). I think we also need to make sure that
> some of the changes that went into cordova-3.1.x branches also ended up in
> the refactored master branches.
>
> I will plan on doing the plugins release tomorrow/Wednesday.
>
> Steve
>
>
> On Mon, Oct 7, 2013 at 3:16 PM, Andrew Grieve wrote:
>
>> I remember someone said the refactoring broke ffos. Not sure if that's
>> fixed yet?
>>
>> Other than that, sounds great to release both this week. Would be good to
>> do them together so as to have a shared blog post.
>>
>>
>> On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson > >wrote:
>>
>> > Er, I didn't actually say: for the tools, not yet, maybe later this
>> week.
>> >
>> > Braden
>> >
>> >
>> > On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson > > >wrote:
>> >
>> > > I'll want to have a hand in the next release of the tools, because of
>> the
>> > > refactoring.
>> > >
>> > > Braden
>> > >
>> > >
>> > > On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill > > >wrote:
>> > >
>> > >> Last week as we were finishing off the release, I remember their was
>> > some
>> > >> interest in doing another plugins release this week.
>> > >>
>> > >> I know windows 8 file transfer needs to be updated and Shaz has some
>> iOS
>> > >> releated plugin changes that could be updated as well.
>> > >>
>> > >> Any resistance to me kicking this off and aiming to get out a plugins
>> > >> release tomorrow/wed?
>> > >>
>> > >> We can also do CLI/Plugman releases on a weekly basis. If anyone has
>> a
>> > >> reason to update one of these, let me know and we can kick up a
>> separate
>> > >> thread.
>> > >>
>> > >> I feel like I got a pretty solid understanding of our various release
>> > >> processes over that last two weeks.
>> > >>
>> > >> -Steve
>> > >>
>> > >
>> > >
>> >
>>
>
>

Re: Plugins Release

[Steven Gill]

If we want to do CLI/Plugman, we definitely will need to do more testing
and fix some things (like FFOS). I think we also need to make sure that
some of the changes that went into cordova-3.1.x branches also ended up in
the refactored master branches.

I will plan on doing the plugins release tomorrow/Wednesday.

Steve


On Mon, Oct 7, 2013 at 3:16 PM, Andrew Grieve  wrote:

> I remember someone said the refactoring broke ffos. Not sure if that's
> fixed yet?
>
> Other than that, sounds great to release both this week. Would be good to
> do them together so as to have a shared blog post.
>
>
> On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson  >wrote:
>
> > Er, I didn't actually say: for the tools, not yet, maybe later this week.
> >
> > Braden
> >
> >
> > On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson  > >wrote:
> >
> > > I'll want to have a hand in the next release of the tools, because of
> the
> > > refactoring.
> > >
> > > Braden
> > >
> > >
> > > On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill  > >wrote:
> > >
> > >> Last week as we were finishing off the release, I remember their was
> > some
> > >> interest in doing another plugins release this week.
> > >>
> > >> I know windows 8 file transfer needs to be updated and Shaz has some
> iOS
> > >> releated plugin changes that could be updated as well.
> > >>
> > >> Any resistance to me kicking this off and aiming to get out a plugins
> > >> release tomorrow/wed?
> > >>
> > >> We can also do CLI/Plugman releases on a weekly basis. If anyone has a
> > >> reason to update one of these, let me know and we can kick up a
> separate
> > >> thread.
> > >>
> > >> I feel like I got a pretty solid understanding of our various release
> > >> processes over that last two weeks.
> > >>
> > >> -Steve
> > >>
> > >
> > >
> >
>

Re: Plugins Release

[Andrew Grieve]

I remember someone said the refactoring broke ffos. Not sure if that's
fixed yet?

Other than that, sounds great to release both this week. Would be good to
do them together so as to have a shared blog post.


On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson wrote:

> Er, I didn't actually say: for the tools, not yet, maybe later this week.
>
> Braden
>
>
> On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson  >wrote:
>
> > I'll want to have a hand in the next release of the tools, because of the
> > refactoring.
> >
> > Braden
> >
> >
> > On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill  >wrote:
> >
> >> Last week as we were finishing off the release, I remember their was
> some
> >> interest in doing another plugins release this week.
> >>
> >> I know windows 8 file transfer needs to be updated and Shaz has some iOS
> >> releated plugin changes that could be updated as well.
> >>
> >> Any resistance to me kicking this off and aiming to get out a plugins
> >> release tomorrow/wed?
> >>
> >> We can also do CLI/Plugman releases on a weekly basis. If anyone has a
> >> reason to update one of these, let me know and we can kick up a separate
> >> thread.
> >>
> >> I feel like I got a pretty solid understanding of our various release
> >> processes over that last two weeks.
> >>
> >> -Steve
> >>
> >
> >
>

Re: Plugins Release

[Braden Shepherdson]

Er, I didn't actually say: for the tools, not yet, maybe later this week.

Braden


On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson wrote:

> I'll want to have a hand in the next release of the tools, because of the
> refactoring.
>
> Braden
>
>
> On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill wrote:
>
>> Last week as we were finishing off the release, I remember their was some
>> interest in doing another plugins release this week.
>>
>> I know windows 8 file transfer needs to be updated and Shaz has some iOS
>> releated plugin changes that could be updated as well.
>>
>> Any resistance to me kicking this off and aiming to get out a plugins
>> release tomorrow/wed?
>>
>> We can also do CLI/Plugman releases on a weekly basis. If anyone has a
>> reason to update one of these, let me know and we can kick up a separate
>> thread.
>>
>> I feel like I got a pretty solid understanding of our various release
>> processes over that last two weeks.
>>
>> -Steve
>>
>
>

Re: Plugins Release

[Braden Shepherdson]

I'll want to have a hand in the next release of the tools, because of the
refactoring.

Braden


On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill  wrote:

> Last week as we were finishing off the release, I remember their was some
> interest in doing another plugins release this week.
>
> I know windows 8 file transfer needs to be updated and Shaz has some iOS
> releated plugin changes that could be updated as well.
>
> Any resistance to me kicking this off and aiming to get out a plugins
> release tomorrow/wed?
>
> We can also do CLI/Plugman releases on a weekly basis. If anyone has a
> reason to update one of these, let me know and we can kick up a separate
> thread.
>
> I feel like I got a pretty solid understanding of our various release
> processes over that last two weeks.
>
> -Steve
>

Re: Plugins Release blog post

[Andrew Grieve]

best to review the .md file instead.
I don't think there's a good way to host it somewhere, other than for you
to download and apply the patch, and run "rake serve" yourself.


On Fri, Sep 27, 2013 at 7:49 PM, Tim Kim  wrote:

> Can we serve the html doc somewhere? I'd rather not read a diff on html.
>
>
> On 26 September 2013 18:08, Steven Gill  wrote:
>
> > Looks like I forgot to click publish on the review page. I also found a
> > bunch of spelling mistakes I made in my rush to create this. I just fixed
> > them and uploaded a new diff. The review site should be available for all
> > now to leave feedback.
> >
> >
> > On Thu, Sep 26, 2013 at 5:42 PM, Steven Gill 
> > wrote:
> >
> > > Today we are doing a big plugin release in preperation for Apache
> Cordova
> > > 3.1.0 which is scheduled to come out next week.
> > >
> > > The main change for this release is removing core from all of the
> plugin
> > > ID fields. This was done to make installing plugins easier in 3.1.0. We
> > are
> > > switching over to using plugin IDs and ourplugin registery<
> > http://plugins.cordova.io/> for
> > > plugin installation instead of directly installing from the plugin git
> > urls.
> > >
> > > These plugins are compatitable with Cordova 3.0.0. Feel free to upgrade
> > > your current plugins if you can’t wait for 3.1.0 next week. Keep in
> mind
> > > that after you install these update plugins, if you decide to remove
> > these
> > > plugins from your project, you will have to reference the new IDs
> instead
> > > of the old ones that our docs show. Ex: ‘cordova rm
> > > org.apache.cordova.camera’ instead of ‘org.apache.cordova.core.camera’.
> > >
> > > *Other Notable Changes:*
> > >
> > >- Firefox OS support for Vibration and Device Plugin
> > >- Windows 8 support for multiple plugins
> > >- Fixed warnings that arose with XCode 5
> > >- CB-4847 iOS 7 microphone access requires user permission (media
> > >plugin)
> > >- CB-4799 Fix incorrect JS references within native code for iOS &
> > >Andrid (media plugin)
> > >- CB-4806 Update splashscreen image bounds for iOS 7 (splashscreen
> > >plugin)
> > >- CB-4593 Added vibration support for BB10 (vibration plugin)
> > >
> > > You can check out the individual release notes in each of the plugin
> > repos
> > > for more details.
> > >
> > >
> > > On Thu, Sep 26, 2013 at 5:37 PM, Steven Gill  > >wrote:
> > >
> > >> I have no idea how this review stuff works. I will post the blog here
> > >> On Sep 26, 2013 4:59 PM, "Tim Kim"  wrote:
> > >>
> > >>> >
> > >>> > "You don't have access to this review request.
> > >>> > This review request is private. You must be a requested reviewer,
> > >>> either
> > >>> > directly or on a requested group, and have permission to access the
> > >>> > repository in order to view this review request."
> > >>>
> > >>> Ya, same here
> > >>>
> > >>>
> > >>> On 26 September 2013 16:37, Shazron  wrote:
> > >>>
> > >>> > Does everyone have access to this? I get:
> > >>> >
> > >>> > "You don't have access to this review request.
> > >>> > This review request is private. You must be a requested reviewer,
> > >>> either
> > >>> > directly or on a requested group, and have permission to access the
> > >>> > repository in order to view this review request."
> > >>> >
> > >>> >
> > >>> > On Thu, Sep 26, 2013 at 4:30 PM, Steven Gill <
> stevengil...@gmail.com
> > >
> > >>> > wrote:
> > >>> >
> > >>> > > Can you guys review it at https://reviews.apache.org/r/14356/
> > >>> > >
> > >>> > > I don't think post-review was working properly for me...
> > >>> > >
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Timothy Kim
> > >>>
> > >>
> > >
> >
>
>
>
> --
> Timothy Kim
>

Re: Plugins Release blog post

[Tim Kim]

Can we serve the html doc somewhere? I'd rather not read a diff on html.


On 26 September 2013 18:08, Steven Gill  wrote:

> Looks like I forgot to click publish on the review page. I also found a
> bunch of spelling mistakes I made in my rush to create this. I just fixed
> them and uploaded a new diff. The review site should be available for all
> now to leave feedback.
>
>
> On Thu, Sep 26, 2013 at 5:42 PM, Steven Gill 
> wrote:
>
> > Today we are doing a big plugin release in preperation for Apache Cordova
> > 3.1.0 which is scheduled to come out next week.
> >
> > The main change for this release is removing core from all of the plugin
> > ID fields. This was done to make installing plugins easier in 3.1.0. We
> are
> > switching over to using plugin IDs and ourplugin registery<
> http://plugins.cordova.io/> for
> > plugin installation instead of directly installing from the plugin git
> urls.
> >
> > These plugins are compatitable with Cordova 3.0.0. Feel free to upgrade
> > your current plugins if you can’t wait for 3.1.0 next week. Keep in mind
> > that after you install these update plugins, if you decide to remove
> these
> > plugins from your project, you will have to reference the new IDs instead
> > of the old ones that our docs show. Ex: ‘cordova rm
> > org.apache.cordova.camera’ instead of ‘org.apache.cordova.core.camera’.
> >
> > *Other Notable Changes:*
> >
> >- Firefox OS support for Vibration and Device Plugin
> >- Windows 8 support for multiple plugins
> >- Fixed warnings that arose with XCode 5
> >- CB-4847 iOS 7 microphone access requires user permission (media
> >plugin)
> >- CB-4799 Fix incorrect JS references within native code for iOS &
> >Andrid (media plugin)
> >- CB-4806 Update splashscreen image bounds for iOS 7 (splashscreen
> >plugin)
> >- CB-4593 Added vibration support for BB10 (vibration plugin)
> >
> > You can check out the individual release notes in each of the plugin
> repos
> > for more details.
> >
> >
> > On Thu, Sep 26, 2013 at 5:37 PM, Steven Gill  >wrote:
> >
> >> I have no idea how this review stuff works. I will post the blog here
> >> On Sep 26, 2013 4:59 PM, "Tim Kim"  wrote:
> >>
> >>> >
> >>> > "You don't have access to this review request.
> >>> > This review request is private. You must be a requested reviewer,
> >>> either
> >>> > directly or on a requested group, and have permission to access the
> >>> > repository in order to view this review request."
> >>>
> >>> Ya, same here
> >>>
> >>>
> >>> On 26 September 2013 16:37, Shazron  wrote:
> >>>
> >>> > Does everyone have access to this? I get:
> >>> >
> >>> > "You don't have access to this review request.
> >>> > This review request is private. You must be a requested reviewer,
> >>> either
> >>> > directly or on a requested group, and have permission to access the
> >>> > repository in order to view this review request."
> >>> >
> >>> >
> >>> > On Thu, Sep 26, 2013 at 4:30 PM, Steven Gill  >
> >>> > wrote:
> >>> >
> >>> > > Can you guys review it at https://reviews.apache.org/r/14356/
> >>> > >
> >>> > > I don't think post-review was working properly for me...
> >>> > >
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Timothy Kim
> >>>
> >>
> >
>



-- 
Timothy Kim

Re: Plugins Release blog post

[Steven Gill]

Looks like I forgot to click publish on the review page. I also found a
bunch of spelling mistakes I made in my rush to create this. I just fixed
them and uploaded a new diff. The review site should be available for all
now to leave feedback.


On Thu, Sep 26, 2013 at 5:42 PM, Steven Gill  wrote:

> Today we are doing a big plugin release in preperation for Apache Cordova
> 3.1.0 which is scheduled to come out next week.
>
> The main change for this release is removing core from all of the plugin
> ID fields. This was done to make installing plugins easier in 3.1.0. We are
> switching over to using plugin IDs and ourplugin 
> registery for
> plugin installation instead of directly installing from the plugin git urls.
>
> These plugins are compatitable with Cordova 3.0.0. Feel free to upgrade
> your current plugins if you can’t wait for 3.1.0 next week. Keep in mind
> that after you install these update plugins, if you decide to remove these
> plugins from your project, you will have to reference the new IDs instead
> of the old ones that our docs show. Ex: ‘cordova rm
> org.apache.cordova.camera’ instead of ‘org.apache.cordova.core.camera’.
>
> *Other Notable Changes:*
>
>- Firefox OS support for Vibration and Device Plugin
>- Windows 8 support for multiple plugins
>- Fixed warnings that arose with XCode 5
>- CB-4847 iOS 7 microphone access requires user permission (media
>plugin)
>- CB-4799 Fix incorrect JS references within native code for iOS &
>Andrid (media plugin)
>- CB-4806 Update splashscreen image bounds for iOS 7 (splashscreen
>plugin)
>- CB-4593 Added vibration support for BB10 (vibration plugin)
>
> You can check out the individual release notes in each of the plugin repos
> for more details.
>
>
> On Thu, Sep 26, 2013 at 5:37 PM, Steven Gill wrote:
>
>> I have no idea how this review stuff works. I will post the blog here
>> On Sep 26, 2013 4:59 PM, "Tim Kim"  wrote:
>>
>>> >
>>> > "You don't have access to this review request.
>>> > This review request is private. You must be a requested reviewer,
>>> either
>>> > directly or on a requested group, and have permission to access the
>>> > repository in order to view this review request."
>>>
>>> Ya, same here
>>>
>>>
>>> On 26 September 2013 16:37, Shazron  wrote:
>>>
>>> > Does everyone have access to this? I get:
>>> >
>>> > "You don't have access to this review request.
>>> > This review request is private. You must be a requested reviewer,
>>> either
>>> > directly or on a requested group, and have permission to access the
>>> > repository in order to view this review request."
>>> >
>>> >
>>> > On Thu, Sep 26, 2013 at 4:30 PM, Steven Gill 
>>> > wrote:
>>> >
>>> > > Can you guys review it at https://reviews.apache.org/r/14356/
>>> > >
>>> > > I don't think post-review was working properly for me...
>>> > >
>>> >
>>>
>>>
>>>
>>> --
>>> Timothy Kim
>>>
>>
>

Re: Plugins Release blog post

[Steven Gill]

Today we are doing a big plugin release in preperation for Apache Cordova
3.1.0 which is scheduled to come out next week.

The main change for this release is removing core from all of the plugin ID
fields. This was done to make installing plugins easier in 3.1.0. We are
switching over to using plugin IDs and ourplugin
registery for
plugin installation instead of directly installing from the plugin git urls.

These plugins are compatitable with Cordova 3.0.0. Feel free to upgrade
your current plugins if you can’t wait for 3.1.0 next week. Keep in mind
that after you install these update plugins, if you decide to remove these
plugins from your project, you will have to reference the new IDs instead
of the old ones that our docs show. Ex: ‘cordova rm
org.apache.cordova.camera’ instead of ‘org.apache.cordova.core.camera’.

*Other Notable Changes:*

   - Firefox OS support for Vibration and Device Plugin
   - Windows 8 support for multiple plugins
   - Fixed warnings that arose with XCode 5
   - CB-4847 iOS 7 microphone access requires user permission (media plugin)
   - CB-4799 Fix incorrect JS references within native code for iOS &
   Andrid (media plugin)
   - CB-4806 Update splashscreen image bounds for iOS 7 (splashscreen
   plugin)
   - CB-4593 Added vibration support for BB10 (vibration plugin)

You can check out the individual release notes in each of the plugin repos
for more details.


On Thu, Sep 26, 2013 at 5:37 PM, Steven Gill  wrote:

> I have no idea how this review stuff works. I will post the blog here
> On Sep 26, 2013 4:59 PM, "Tim Kim"  wrote:
>
>> >
>> > "You don't have access to this review request.
>> > This review request is private. You must be a requested reviewer, either
>> > directly or on a requested group, and have permission to access the
>> > repository in order to view this review request."
>>
>> Ya, same here
>>
>>
>> On 26 September 2013 16:37, Shazron  wrote:
>>
>> > Does everyone have access to this? I get:
>> >
>> > "You don't have access to this review request.
>> > This review request is private. You must be a requested reviewer, either
>> > directly or on a requested group, and have permission to access the
>> > repository in order to view this review request."
>> >
>> >
>> > On Thu, Sep 26, 2013 at 4:30 PM, Steven Gill 
>> > wrote:
>> >
>> > > Can you guys review it at https://reviews.apache.org/r/14356/
>> > >
>> > > I don't think post-review was working properly for me...
>> > >
>> >
>>
>>
>>
>> --
>> Timothy Kim
>>
>

Re: Plugins Release blog post

[Steven Gill]

I have no idea how this review stuff works. I will post the blog here
On Sep 26, 2013 4:59 PM, "Tim Kim"  wrote:

> >
> > "You don't have access to this review request.
> > This review request is private. You must be a requested reviewer, either
> > directly or on a requested group, and have permission to access the
> > repository in order to view this review request."
>
> Ya, same here
>
>
> On 26 September 2013 16:37, Shazron  wrote:
>
> > Does everyone have access to this? I get:
> >
> > "You don't have access to this review request.
> > This review request is private. You must be a requested reviewer, either
> > directly or on a requested group, and have permission to access the
> > repository in order to view this review request."
> >
> >
> > On Thu, Sep 26, 2013 at 4:30 PM, Steven Gill 
> > wrote:
> >
> > > Can you guys review it at https://reviews.apache.org/r/14356/
> > >
> > > I don't think post-review was working properly for me...
> > >
> >
>
>
>
> --
> Timothy Kim
>

Re: Plugins Release blog post

[Tim Kim]

>
> "You don't have access to this review request.
> This review request is private. You must be a requested reviewer, either
> directly or on a requested group, and have permission to access the
> repository in order to view this review request."

Ya, same here


On 26 September 2013 16:37, Shazron  wrote:

> Does everyone have access to this? I get:
>
> "You don't have access to this review request.
> This review request is private. You must be a requested reviewer, either
> directly or on a requested group, and have permission to access the
> repository in order to view this review request."
>
>
> On Thu, Sep 26, 2013 at 4:30 PM, Steven Gill 
> wrote:
>
> > Can you guys review it at https://reviews.apache.org/r/14356/
> >
> > I don't think post-review was working properly for me...
> >
>



-- 
Timothy Kim

Re: Plugins Release blog post

[Shazron]

Does everyone have access to this? I get:

"You don't have access to this review request.
This review request is private. You must be a requested reviewer, either
directly or on a requested group, and have permission to access the
repository in order to view this review request."


On Thu, Sep 26, 2013 at 4:30 PM, Steven Gill  wrote:

> Can you guys review it at https://reviews.apache.org/r/14356/
>
> I don't think post-review was working properly for me...
>