cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benn Mapes <benn.ma...@gmail.com>
Subject Re: Friendly reminder re: Core API patches
Date Wed, 05 Jun 2013 21:06:03 GMT
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 <fil@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" <mmocny@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 <fil@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" <fil@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
> >> >>
> >> >
> >>
>
>

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