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 <benn.ma...@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 <f...@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" <mmo...@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 <f...@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" <f...@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 > > >> >> > > >> > > > >> > > > > >
