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 <bra...@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 <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 >> > >> >> >> > >> > >> > >> >> > >> > >>