Friendly reminder re: Core API patches

[Filip Maj <fi...@adobe.com>]

A lot of work is being put into breaking out the plugins into individual
repositories, as a prep for 3.0. One of my goals on this project is to
ship a Cordova for 3.0 that allows users to compose a cordova application
shell with whatever plugins they wish, including the core APIs. This way
users don't need to bundle all core APIs (and related permissions, etc.)
with every app they build.

So just a friendly reminder that, if you are patching a particular core
API, be it javascript or native code, please remember to also patch the
plugin repository with the same commit. I understand it can be a bit of
pain to double-up your work, but this should be a temporary thing that
will no longer be necessary post-3.0.

Related to this: if anyone is curious about what the cordova libraries
will look like for 3.0, there are long-lived 3.0 branches being worked on
on all the main cordova implementations (android, blackberry, iOS, and the
windows phones) where the core APIs are being ripped out, and any weird
coupling between API code and the underlying framework is being slowly
teased out.

Thank you! :)

Fil

Re: Friendly reminder re: Core API patches

[Brian LeRoux <b...@brian.io>]

Super true. I am personally very excited for the future wherein we can
iterate the plugins independently (and thusly version).

On Thu, Jun 6, 2013 at 9:54 AM, Braden Shepherdson <br...@chromium.org> wrote:
> It's worth remembering that despite the substantial changes of 3.0, most of
> the code backing the APIs has not changed, only moved. Therefore if a bug
> exists in 2.x, it will likely exist in 3.0 also. This is especially true of
> the bug hotbeds like FileTransfer.
>
> Braden
>
>
> On Wed, Jun 5, 2013 at 5:06 PM, Benn Mapes <be...@gmail.com> wrote:
>
>> I like the idea of keeping 2.x around and updating it to fix any bugs filed
>> for 2.x
>>
>> As for when to break out the plugins and merge/rebase the 3.0 branch, this
>> should wait until after 2.9.x is released. Otherwise the users would need
>> node/plugman in order to create a project, and this is a dependency that we
>> probably
>> shouldn't introduce until 3.0. That being said, we should be keeping the
>> 3.0 branches
>> up to date with the current master so that the transition is smooth and we
>> don't
>> have any crazy merge problems; this also allows us to continually test the
>> 3.0
>> branches as if it were already merged into master.
>>
>>
>> On Wed, Jun 5, 2013 at 1:04 PM, Filip Maj <fi...@adobe.com> wrote:
>>
>> > There's merits to both and I'm open to either approach. To summarize:
>> >
>> > - dump the 3.0 branch into master now, and expand the ./create scripts so
>> > that they call into plugman to re-add the core apis. Pro: gives us more
>> > time to bake the frameworks with plugins ripped out. Con: probably not
>> > ready right now and we have to do a whole lot of work to support pre-3.0
>> > peeps.
>> > - wait til we branch 2.9.x, THEN dump 3.0 into master. Pro: gives us a
>> bit
>> > more time to ready the individual plugin repos. Con: less time to bake
>> > leading up to 3.0.
>> >
>> > On 6/5/13 12:34 PM, "Michal Mocny" <mm...@chromium.org> wrote:
>> >
>> > >+1.
>> > >
>> > >However, do we want to support 2.x for some extended time during the
>> > >tooling transition to 3.x for everyone?  One way to do this is just
>> land a
>> > >constant stream of point releases on the 2.9.x branch.  Another way
>> could
>> > >be to branch a 2.x long-lived feature branch before merging in 3.0.0 and
>> > >continue to work on that for as long as we think we need to (sorta like
>> > >python 2.x and 3.x are both long lived).
>> > >
>> > >Personally, I'de prefer to jump all-in on 3.x and do at most do a few
>> > >2.9.x
>> > >point releases.
>> > >
>> > >-Michal
>> > >
>> > >
>> > >On Wed, Jun 5, 2013 at 2:43 PM, Brian LeRoux <b...@brian.io> wrote:
>> > >
>> > >> +1
>> > >>
>> > >> Lets do that nao.
>> > >>
>> > >>
>> > >> On Wed, Jun 5, 2013 at 12:11 PM, Filip Maj <fi...@adobe.com> wrote:
>> > >> > Joe and I were just talking about how the process of integrating an
>> > >> > API-less cordova (I.e. The 3.0 branches) back into the master
>> branches
>> > >> > would work. I imagine that, as soon as we create a release branch
>> for
>> > >> > 2.9.0 / tag 2.9.0rc1, we will merge/rebase the 3.0 branch into
>> master
>> > >> > right away. Then we can have all committers/contributors start
>> > >> > iterating/testing the composable plugin/api approach right off the
>> > >>master
>> > >> > branch, in prep for 3.0.
>> > >> >
>> > >> > On 6/5/13 9:52 AM, "Filip Maj" <fi...@adobe.com> wrote:
>> > >> >
>> > >> >>A lot of work is being put into breaking out the plugins into
>> > >>individual
>> > >> >>repositories, as a prep for 3.0. One of my goals on this project is
>> to
>> > >> >>ship a Cordova for 3.0 that allows users to compose a cordova
>> > >>application
>> > >> >>shell with whatever plugins they wish, including the core APIs. This
>> > >>way
>> > >> >>users don't need to bundle all core APIs (and related permissions,
>> > >>etc.)
>> > >> >>with every app they build.
>> > >> >>
>> > >> >>So just a friendly reminder that, if you are patching a particular
>> > >>core
>> > >> >>API, be it javascript or native code, please remember to also patch
>> > >>the
>> > >> >>plugin repository with the same commit. I understand it can be a bit
>> > >>of
>> > >> >>pain to double-up your work, but this should be a temporary thing
>> that
>> > >> >>will no longer be necessary post-3.0.
>> > >> >>
>> > >> >>Related to this: if anyone is curious about what the cordova
>> libraries
>> > >> >>will look like for 3.0, there are long-lived 3.0 branches being
>> > >>worked on
>> > >> >>on all the main cordova implementations (android, blackberry, iOS,
>> and
>> > >> the
>> > >> >>windows phones) where the core APIs are being ripped out, and any
>> > >>weird
>> > >> >>coupling between API code and the underlying framework is being
>> slowly
>> > >> >>teased out.
>> > >> >>
>> > >> >>Thank you! :)
>> > >> >>
>> > >> >>Fil
>> > >> >>
>> > >> >
>> > >>
>> >
>> >
>>

Re: Friendly reminder re: Core API patches

[Braden Shepherdson <br...@chromium.org>]

It's worth remembering that despite the substantial changes of 3.0, most of
the code backing the APIs has not changed, only moved. Therefore if a bug
exists in 2.x, it will likely exist in 3.0 also. This is especially true of
the bug hotbeds like FileTransfer.

Braden


On Wed, Jun 5, 2013 at 5:06 PM, Benn Mapes <be...@gmail.com> wrote:

> I like the idea of keeping 2.x around and updating it to fix any bugs filed
> for 2.x
>
> As for when to break out the plugins and merge/rebase the 3.0 branch, this
> should wait until after 2.9.x is released. Otherwise the users would need
> node/plugman in order to create a project, and this is a dependency that we
> probably
> shouldn't introduce until 3.0. That being said, we should be keeping the
> 3.0 branches
> up to date with the current master so that the transition is smooth and we
> don't
> have any crazy merge problems; this also allows us to continually test the
> 3.0
> branches as if it were already merged into master.
>
>
> On Wed, Jun 5, 2013 at 1:04 PM, Filip Maj <fi...@adobe.com> wrote:
>
> > There's merits to both and I'm open to either approach. To summarize:
> >
> > - dump the 3.0 branch into master now, and expand the ./create scripts so
> > that they call into plugman to re-add the core apis. Pro: gives us more
> > time to bake the frameworks with plugins ripped out. Con: probably not
> > ready right now and we have to do a whole lot of work to support pre-3.0
> > peeps.
> > - wait til we branch 2.9.x, THEN dump 3.0 into master. Pro: gives us a
> bit
> > more time to ready the individual plugin repos. Con: less time to bake
> > leading up to 3.0.
> >
> > On 6/5/13 12:34 PM, "Michal Mocny" <mm...@chromium.org> wrote:
> >
> > >+1.
> > >
> > >However, do we want to support 2.x for some extended time during the
> > >tooling transition to 3.x for everyone?  One way to do this is just
> land a
> > >constant stream of point releases on the 2.9.x branch.  Another way
> could
> > >be to branch a 2.x long-lived feature branch before merging in 3.0.0 and
> > >continue to work on that for as long as we think we need to (sorta like
> > >python 2.x and 3.x are both long lived).
> > >
> > >Personally, I'de prefer to jump all-in on 3.x and do at most do a few
> > >2.9.x
> > >point releases.
> > >
> > >-Michal
> > >
> > >
> > >On Wed, Jun 5, 2013 at 2:43 PM, Brian LeRoux <b...@brian.io> wrote:
> > >
> > >> +1
> > >>
> > >> Lets do that nao.
> > >>
> > >>
> > >> On Wed, Jun 5, 2013 at 12:11 PM, Filip Maj <fi...@adobe.com> wrote:
> > >> > Joe and I were just talking about how the process of integrating an
> > >> > API-less cordova (I.e. The 3.0 branches) back into the master
> branches
> > >> > would work. I imagine that, as soon as we create a release branch
> for
> > >> > 2.9.0 / tag 2.9.0rc1, we will merge/rebase the 3.0 branch into
> master
> > >> > right away. Then we can have all committers/contributors start
> > >> > iterating/testing the composable plugin/api approach right off the
> > >>master
> > >> > branch, in prep for 3.0.
> > >> >
> > >> > On 6/5/13 9:52 AM, "Filip Maj" <fi...@adobe.com> wrote:
> > >> >
> > >> >>A lot of work is being put into breaking out the plugins into
> > >>individual
> > >> >>repositories, as a prep for 3.0. One of my goals on this project is
> to
> > >> >>ship a Cordova for 3.0 that allows users to compose a cordova
> > >>application
> > >> >>shell with whatever plugins they wish, including the core APIs. This
> > >>way
> > >> >>users don't need to bundle all core APIs (and related permissions,
> > >>etc.)
> > >> >>with every app they build.
> > >> >>
> > >> >>So just a friendly reminder that, if you are patching a particular
> > >>core
> > >> >>API, be it javascript or native code, please remember to also patch
> > >>the
> > >> >>plugin repository with the same commit. I understand it can be a bit
> > >>of
> > >> >>pain to double-up your work, but this should be a temporary thing
> that
> > >> >>will no longer be necessary post-3.0.
> > >> >>
> > >> >>Related to this: if anyone is curious about what the cordova
> libraries
> > >> >>will look like for 3.0, there are long-lived 3.0 branches being
> > >>worked on
> > >> >>on all the main cordova implementations (android, blackberry, iOS,
> and
> > >> the
> > >> >>windows phones) where the core APIs are being ripped out, and any
> > >>weird
> > >> >>coupling between API code and the underlying framework is being
> slowly
> > >> >>teased out.
> > >> >>
> > >> >>Thank you! :)
> > >> >>
> > >> >>Fil
> > >> >>
> > >> >
> > >>
> >
> >
>

Re: Friendly reminder re: Core API patches

[Benn Mapes <be...@gmail.com>]

I like the idea of keeping 2.x around and updating it to fix any bugs filed
for 2.x

As for when to break out the plugins and merge/rebase the 3.0 branch, this
should wait until after 2.9.x is released. Otherwise the users would need
node/plugman in order to create a project, and this is a dependency that we
probably
shouldn't introduce until 3.0. That being said, we should be keeping the
3.0 branches
up to date with the current master so that the transition is smooth and we
don't
have any crazy merge problems; this also allows us to continually test the
3.0
branches as if it were already merged into master.


On Wed, Jun 5, 2013 at 1:04 PM, Filip Maj <fi...@adobe.com> wrote:

> There's merits to both and I'm open to either approach. To summarize:
>
> - dump the 3.0 branch into master now, and expand the ./create scripts so
> that they call into plugman to re-add the core apis. Pro: gives us more
> time to bake the frameworks with plugins ripped out. Con: probably not
> ready right now and we have to do a whole lot of work to support pre-3.0
> peeps.
> - wait til we branch 2.9.x, THEN dump 3.0 into master. Pro: gives us a bit
> more time to ready the individual plugin repos. Con: less time to bake
> leading up to 3.0.
>
> On 6/5/13 12:34 PM, "Michal Mocny" <mm...@chromium.org> wrote:
>
> >+1.
> >
> >However, do we want to support 2.x for some extended time during the
> >tooling transition to 3.x for everyone?  One way to do this is just land a
> >constant stream of point releases on the 2.9.x branch.  Another way could
> >be to branch a 2.x long-lived feature branch before merging in 3.0.0 and
> >continue to work on that for as long as we think we need to (sorta like
> >python 2.x and 3.x are both long lived).
> >
> >Personally, I'de prefer to jump all-in on 3.x and do at most do a few
> >2.9.x
> >point releases.
> >
> >-Michal
> >
> >
> >On Wed, Jun 5, 2013 at 2:43 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> >> +1
> >>
> >> Lets do that nao.
> >>
> >>
> >> On Wed, Jun 5, 2013 at 12:11 PM, Filip Maj <fi...@adobe.com> wrote:
> >> > Joe and I were just talking about how the process of integrating an
> >> > API-less cordova (I.e. The 3.0 branches) back into the master branches
> >> > would work. I imagine that, as soon as we create a release branch for
> >> > 2.9.0 / tag 2.9.0rc1, we will merge/rebase the 3.0 branch into master
> >> > right away. Then we can have all committers/contributors start
> >> > iterating/testing the composable plugin/api approach right off the
> >>master
> >> > branch, in prep for 3.0.
> >> >
> >> > On 6/5/13 9:52 AM, "Filip Maj" <fi...@adobe.com> wrote:
> >> >
> >> >>A lot of work is being put into breaking out the plugins into
> >>individual
> >> >>repositories, as a prep for 3.0. One of my goals on this project is to
> >> >>ship a Cordova for 3.0 that allows users to compose a cordova
> >>application
> >> >>shell with whatever plugins they wish, including the core APIs. This
> >>way
> >> >>users don't need to bundle all core APIs (and related permissions,
> >>etc.)
> >> >>with every app they build.
> >> >>
> >> >>So just a friendly reminder that, if you are patching a particular
> >>core
> >> >>API, be it javascript or native code, please remember to also patch
> >>the
> >> >>plugin repository with the same commit. I understand it can be a bit
> >>of
> >> >>pain to double-up your work, but this should be a temporary thing that
> >> >>will no longer be necessary post-3.0.
> >> >>
> >> >>Related to this: if anyone is curious about what the cordova libraries
> >> >>will look like for 3.0, there are long-lived 3.0 branches being
> >>worked on
> >> >>on all the main cordova implementations (android, blackberry, iOS, and
> >> the
> >> >>windows phones) where the core APIs are being ripped out, and any
> >>weird
> >> >>coupling between API code and the underlying framework is being slowly
> >> >>teased out.
> >> >>
> >> >>Thank you! :)
> >> >>
> >> >>Fil
> >> >>
> >> >
> >>
>
>

Re: Friendly reminder re: Core API patches

[Filip Maj <fi...@adobe.com>]

There's merits to both and I'm open to either approach. To summarize:

- dump the 3.0 branch into master now, and expand the ./create scripts so
that they call into plugman to re-add the core apis. Pro: gives us more
time to bake the frameworks with plugins ripped out. Con: probably not
ready right now and we have to do a whole lot of work to support pre-3.0
peeps.
- wait til we branch 2.9.x, THEN dump 3.0 into master. Pro: gives us a bit
more time to ready the individual plugin repos. Con: less time to bake
leading up to 3.0.

On 6/5/13 12:34 PM, "Michal Mocny" <mm...@chromium.org> wrote:

>+1.
>
>However, do we want to support 2.x for some extended time during the
>tooling transition to 3.x for everyone?  One way to do this is just land a
>constant stream of point releases on the 2.9.x branch.  Another way could
>be to branch a 2.x long-lived feature branch before merging in 3.0.0 and
>continue to work on that for as long as we think we need to (sorta like
>python 2.x and 3.x are both long lived).
>
>Personally, I'de prefer to jump all-in on 3.x and do at most do a few
>2.9.x
>point releases.
>
>-Michal
>
>
>On Wed, Jun 5, 2013 at 2:43 PM, Brian LeRoux <b...@brian.io> wrote:
>
>> +1
>>
>> Lets do that nao.
>>
>>
>> On Wed, Jun 5, 2013 at 12:11 PM, Filip Maj <fi...@adobe.com> wrote:
>> > Joe and I were just talking about how the process of integrating an
>> > API-less cordova (I.e. The 3.0 branches) back into the master branches
>> > would work. I imagine that, as soon as we create a release branch for
>> > 2.9.0 / tag 2.9.0rc1, we will merge/rebase the 3.0 branch into master
>> > right away. Then we can have all committers/contributors start
>> > iterating/testing the composable plugin/api approach right off the
>>master
>> > branch, in prep for 3.0.
>> >
>> > On 6/5/13 9:52 AM, "Filip Maj" <fi...@adobe.com> wrote:
>> >
>> >>A lot of work is being put into breaking out the plugins into
>>individual
>> >>repositories, as a prep for 3.0. One of my goals on this project is to
>> >>ship a Cordova for 3.0 that allows users to compose a cordova
>>application
>> >>shell with whatever plugins they wish, including the core APIs. This
>>way
>> >>users don't need to bundle all core APIs (and related permissions,
>>etc.)
>> >>with every app they build.
>> >>
>> >>So just a friendly reminder that, if you are patching a particular
>>core
>> >>API, be it javascript or native code, please remember to also patch
>>the
>> >>plugin repository with the same commit. I understand it can be a bit
>>of
>> >>pain to double-up your work, but this should be a temporary thing that
>> >>will no longer be necessary post-3.0.
>> >>
>> >>Related to this: if anyone is curious about what the cordova libraries
>> >>will look like for 3.0, there are long-lived 3.0 branches being
>>worked on
>> >>on all the main cordova implementations (android, blackberry, iOS, and
>> the
>> >>windows phones) where the core APIs are being ripped out, and any
>>weird
>> >>coupling between API code and the underlying framework is being slowly
>> >>teased out.
>> >>
>> >>Thank you! :)
>> >>
>> >>Fil
>> >>
>> >
>>

Re: Friendly reminder re: Core API patches

[Michal Mocny <mm...@chromium.org>]

+1.

However, do we want to support 2.x for some extended time during the
tooling transition to 3.x for everyone?  One way to do this is just land a
constant stream of point releases on the 2.9.x branch.  Another way could
be to branch a 2.x long-lived feature branch before merging in 3.0.0 and
continue to work on that for as long as we think we need to (sorta like
python 2.x and 3.x are both long lived).

Personally, I'de prefer to jump all-in on 3.x and do at most do a few 2.9.x
point releases.

-Michal


On Wed, Jun 5, 2013 at 2:43 PM, Brian LeRoux <b...@brian.io> wrote:

> +1
>
> Lets do that nao.
>
>
> On Wed, Jun 5, 2013 at 12:11 PM, Filip Maj <fi...@adobe.com> wrote:
> > Joe and I were just talking about how the process of integrating an
> > API-less cordova (I.e. The 3.0 branches) back into the master branches
> > would work. I imagine that, as soon as we create a release branch for
> > 2.9.0 / tag 2.9.0rc1, we will merge/rebase the 3.0 branch into master
> > right away. Then we can have all committers/contributors start
> > iterating/testing the composable plugin/api approach right off the master
> > branch, in prep for 3.0.
> >
> > On 6/5/13 9:52 AM, "Filip Maj" <fi...@adobe.com> wrote:
> >
> >>A lot of work is being put into breaking out the plugins into individual
> >>repositories, as a prep for 3.0. One of my goals on this project is to
> >>ship a Cordova for 3.0 that allows users to compose a cordova application
> >>shell with whatever plugins they wish, including the core APIs. This way
> >>users don't need to bundle all core APIs (and related permissions, etc.)
> >>with every app they build.
> >>
> >>So just a friendly reminder that, if you are patching a particular core
> >>API, be it javascript or native code, please remember to also patch the
> >>plugin repository with the same commit. I understand it can be a bit of
> >>pain to double-up your work, but this should be a temporary thing that
> >>will no longer be necessary post-3.0.
> >>
> >>Related to this: if anyone is curious about what the cordova libraries
> >>will look like for 3.0, there are long-lived 3.0 branches being worked on
> >>on all the main cordova implementations (android, blackberry, iOS, and
> the
> >>windows phones) where the core APIs are being ripped out, and any weird
> >>coupling between API code and the underlying framework is being slowly
> >>teased out.
> >>
> >>Thank you! :)
> >>
> >>Fil
> >>
> >
>

Re: Friendly reminder re: Core API patches

[Brian LeRoux <b...@brian.io>]

+1

Lets do that nao.


On Wed, Jun 5, 2013 at 12:11 PM, Filip Maj <fi...@adobe.com> wrote:
> Joe and I were just talking about how the process of integrating an
> API-less cordova (I.e. The 3.0 branches) back into the master branches
> would work. I imagine that, as soon as we create a release branch for
> 2.9.0 / tag 2.9.0rc1, we will merge/rebase the 3.0 branch into master
> right away. Then we can have all committers/contributors start
> iterating/testing the composable plugin/api approach right off the master
> branch, in prep for 3.0.
>
> On 6/5/13 9:52 AM, "Filip Maj" <fi...@adobe.com> wrote:
>
>>A lot of work is being put into breaking out the plugins into individual
>>repositories, as a prep for 3.0. One of my goals on this project is to
>>ship a Cordova for 3.0 that allows users to compose a cordova application
>>shell with whatever plugins they wish, including the core APIs. This way
>>users don't need to bundle all core APIs (and related permissions, etc.)
>>with every app they build.
>>
>>So just a friendly reminder that, if you are patching a particular core
>>API, be it javascript or native code, please remember to also patch the
>>plugin repository with the same commit. I understand it can be a bit of
>>pain to double-up your work, but this should be a temporary thing that
>>will no longer be necessary post-3.0.
>>
>>Related to this: if anyone is curious about what the cordova libraries
>>will look like for 3.0, there are long-lived 3.0 branches being worked on
>>on all the main cordova implementations (android, blackberry, iOS, and the
>>windows phones) where the core APIs are being ripped out, and any weird
>>coupling between API code and the underlying framework is being slowly
>>teased out.
>>
>>Thank you! :)
>>
>>Fil
>>
>

Re: Friendly reminder re: Core API patches

[Braden Shepherdson <br...@chromium.org>]

Agreed. When the 3.0 branches were created, I said "they should have been
called 'future' or similar", since that's what they really are. The 3.0
branch that we've been working on so far is not the 3.0.x release branch.

Braden


On Wed, Jun 5, 2013 at 1:41 PM, Ian Clelland <ic...@google.com> wrote:

> That makes sense. That is probably the only reason to ever merge such a
> branch back into master -- essentially the 3.0.0 branch that we have now is
> treated as a 'feature' branch, to be merged into master when it is ready
> (and after the long-lived 2.9.x branch splits off).
>
> Then, later, we can actually split off a 3.0.x release branch, a 3.1.x
> release branch, etc.
>
>
> On Wed, Jun 5, 2013 at 1:11 PM, Filip Maj <fi...@adobe.com> wrote:
>
> > Joe and I were just talking about how the process of integrating an
> > API-less cordova (I.e. The 3.0 branches) back into the master branches
> > would work. I imagine that, as soon as we create a release branch for
> > 2.9.0 / tag 2.9.0rc1, we will merge/rebase the 3.0 branch into master
> > right away. Then we can have all committers/contributors start
> > iterating/testing the composable plugin/api approach right off the master
> > branch, in prep for 3.0.
> >
> > On 6/5/13 9:52 AM, "Filip Maj" <fi...@adobe.com> wrote:
> >
> > >A lot of work is being put into breaking out the plugins into individual
> > >repositories, as a prep for 3.0. One of my goals on this project is to
> > >ship a Cordova for 3.0 that allows users to compose a cordova
> application
> > >shell with whatever plugins they wish, including the core APIs. This way
> > >users don't need to bundle all core APIs (and related permissions, etc.)
> > >with every app they build.
> > >
> > >So just a friendly reminder that, if you are patching a particular core
> > >API, be it javascript or native code, please remember to also patch the
> > >plugin repository with the same commit. I understand it can be a bit of
> > >pain to double-up your work, but this should be a temporary thing that
> > >will no longer be necessary post-3.0.
> > >
> > >Related to this: if anyone is curious about what the cordova libraries
> > >will look like for 3.0, there are long-lived 3.0 branches being worked
> on
> > >on all the main cordova implementations (android, blackberry, iOS, and
> the
> > >windows phones) where the core APIs are being ripped out, and any weird
> > >coupling between API code and the underlying framework is being slowly
> > >teased out.
> > >
> > >Thank you! :)
> > >
> > >Fil
> > >
> >
> >
>

Re: Friendly reminder re: Core API patches

[Ian Clelland <ic...@google.com>]

That makes sense. That is probably the only reason to ever merge such a
branch back into master -- essentially the 3.0.0 branch that we have now is
treated as a 'feature' branch, to be merged into master when it is ready
(and after the long-lived 2.9.x branch splits off).

Then, later, we can actually split off a 3.0.x release branch, a 3.1.x
release branch, etc.


On Wed, Jun 5, 2013 at 1:11 PM, Filip Maj <fi...@adobe.com> wrote:

> Joe and I were just talking about how the process of integrating an
> API-less cordova (I.e. The 3.0 branches) back into the master branches
> would work. I imagine that, as soon as we create a release branch for
> 2.9.0 / tag 2.9.0rc1, we will merge/rebase the 3.0 branch into master
> right away. Then we can have all committers/contributors start
> iterating/testing the composable plugin/api approach right off the master
> branch, in prep for 3.0.
>
> On 6/5/13 9:52 AM, "Filip Maj" <fi...@adobe.com> wrote:
>
> >A lot of work is being put into breaking out the plugins into individual
> >repositories, as a prep for 3.0. One of my goals on this project is to
> >ship a Cordova for 3.0 that allows users to compose a cordova application
> >shell with whatever plugins they wish, including the core APIs. This way
> >users don't need to bundle all core APIs (and related permissions, etc.)
> >with every app they build.
> >
> >So just a friendly reminder that, if you are patching a particular core
> >API, be it javascript or native code, please remember to also patch the
> >plugin repository with the same commit. I understand it can be a bit of
> >pain to double-up your work, but this should be a temporary thing that
> >will no longer be necessary post-3.0.
> >
> >Related to this: if anyone is curious about what the cordova libraries
> >will look like for 3.0, there are long-lived 3.0 branches being worked on
> >on all the main cordova implementations (android, blackberry, iOS, and the
> >windows phones) where the core APIs are being ripped out, and any weird
> >coupling between API code and the underlying framework is being slowly
> >teased out.
> >
> >Thank you! :)
> >
> >Fil
> >
>
>

Re: Friendly reminder re: Core API patches

[Filip Maj <fi...@adobe.com>]

Joe and I were just talking about how the process of integrating an
API-less cordova (I.e. The 3.0 branches) back into the master branches
would work. I imagine that, as soon as we create a release branch for
2.9.0 / tag 2.9.0rc1, we will merge/rebase the 3.0 branch into master
right away. Then we can have all committers/contributors start
iterating/testing the composable plugin/api approach right off the master
branch, in prep for 3.0.

On 6/5/13 9:52 AM, "Filip Maj" <fi...@adobe.com> wrote:

>A lot of work is being put into breaking out the plugins into individual
>repositories, as a prep for 3.0. One of my goals on this project is to
>ship a Cordova for 3.0 that allows users to compose a cordova application
>shell with whatever plugins they wish, including the core APIs. This way
>users don't need to bundle all core APIs (and related permissions, etc.)
>with every app they build.
>
>So just a friendly reminder that, if you are patching a particular core
>API, be it javascript or native code, please remember to also patch the
>plugin repository with the same commit. I understand it can be a bit of
>pain to double-up your work, but this should be a temporary thing that
>will no longer be necessary post-3.0.
>
>Related to this: if anyone is curious about what the cordova libraries
>will look like for 3.0, there are long-lived 3.0 branches being worked on
>on all the main cordova implementations (android, blackberry, iOS, and the
>windows phones) where the core APIs are being ripped out, and any weird
>coupling between API code and the underlying framework is being slowly
>teased out.
>
>Thank you! :)
>
>Fil
>