A F2F would help this discussion move forward. I only have two requirements for the F2F:
1. We clarify the topic to be discussed. This thread has touched a breadth of topics from what's possible today to semver-major-breaking changes. 2. The F2F time accommodates Tommy Williams. He's one of the few voices that's still grounded in the goal of this project - enabling developers to create cross-platform mobile apps with web tech. While many of us speculate what our users want or need, he not only uses Cordova daily (i.e. shipping production apps) but supports many other users in our community. I don't think we've given his suggestions enough weight. Michael On Thu, Jun 5, 2014 at 10:45 AM, Michal Mocny <mmo...@chromium.org> wrote: > It actually looks like theres a Cordova Monthly Hangout scheduled for next > Tuesday. > > > On Thu, Jun 5, 2014 at 1:23 PM, Brian LeRoux <b...@brian.io> wrote: > > > 1. Agree w/ Michal: we need to discuss F2F. Want to quickly address some > of > > Andrews comments. > > > > > - start enforcing that Cordova projects are node projects > > > > Node is a dep already. We could look into painting over it and > distributing > > raw binary that vendors Node but there's probably no benefit to it. Point > > is: the CLI *is* a Node project. > > > > > - requiring a tools release every time any of the platforms want to do > a > > release > > > > Agree, we should not do that. But sometimes we will have to (and want > to). > > Software development is all about releasing. It would be great to get > back > > to making releases a non-event that happen with regularity. > > > > > - changing the Cordova workflow in a major way so soon after 3.0 > > > > I am not suggesting a major change to workflow but an incremental > > improvement that we've been discussing for the CLI for a long time. > > > > > > > > On Thu, Jun 5, 2014 at 12:09 PM, Josh Soref <jso...@blackberry.com> > wrote: > > > > > Michal Mocny wrote: > > > > Most plugins will work across a wide range of platform versions, > > > > so often it would work to have disparate platform versions even with > > > plugins. > > > > However, I do concede that in general this isn't a complexity we > focus > > > on. > > > > > > Please note that arbitrary platform implementations choose to drop > > support > > > for actual OS versions arbitrarily. And not in lockstep w/ their fellow > > > platforms. They also choose to add support for actual OS versions > > > arbitrarily. > > > > > > I could easily need to use a slightly older version of platform Y in > > order > > > to retain support for OS Y version Q. But I might want to use a newer > > > version of platform Z in order to support OS Z version P. > > > > > > I'm not saying that this has to be the easiest thing in the world for > me > > > to do, but it should be both doable and documented. > > > > > >
