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" <[email protected]> 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 <[email protected]> wrote: > >> +1 >> >> Lets do that nao. >> >> >> On Wed, Jun 5, 2013 at 12:11 PM, Filip Maj <[email protected]> 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" <[email protected]> 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 >> >> >> > >>
