Return-Path: X-Original-To: apmail-incubator-callback-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-callback-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 93008980D for ; Thu, 29 Mar 2012 18:02:39 +0000 (UTC) Received: (qmail 59371 invoked by uid 500); 29 Mar 2012 18:02:39 -0000 Delivered-To: apmail-incubator-callback-dev-archive@incubator.apache.org Received: (qmail 59326 invoked by uid 500); 29 Mar 2012 18:02:39 -0000 Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: callback-dev@incubator.apache.org Delivered-To: mailing list callback-dev@incubator.apache.org Received: (qmail 59206 invoked by uid 99); 29 Mar 2012 18:02:38 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Mar 2012 18:02:38 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of brian.leroux@gmail.com designates 209.85.214.175 as permitted sender) Received: from [209.85.214.175] (HELO mail-ob0-f175.google.com) (209.85.214.175) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Mar 2012 18:02:32 +0000 Received: by obbwc20 with SMTP id wc20so1794249obb.6 for ; Thu, 29 Mar 2012 11:02:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=2tU0Eur5z/ljI90r7uQWCr9uekR7Wc4z47cKdNk/dA4=; b=Ksp9LAi5Qhnh1sEo1iUmr5RT9abZBDbNNNFe+XGSQVoaYW9xTftBI5DJGPrMuwFjo/ 5DozWvfa8BJw/vOc/OwEbMV6SBUeNxkjy+1S3mjsGX7+0s9MCqmfrZVJVis9amdbjEBu cFc/H5UHCwvEzFjBJ1w0+xWpyYQGqtK2dc8dbah93IgqinUm9WXJqXbY9abkPtRnwR7y cNVRKusGpjvM/ClO7tMqDaPTRp6aFWotc/5HH6D6upgbNNp/jrGWQXfDnWzvFvP6f04D VP3aOPc4vlU5Hi8x+N//VY995h/U/gR5z6IYKmamlWU61HKVNjETrL+QJh2FKB5ODG5M ItCw== MIME-Version: 1.0 Received: by 10.182.192.36 with SMTP id hd4mr45115438obc.60.1333044132117; Thu, 29 Mar 2012 11:02:12 -0700 (PDT) Sender: brian.leroux@gmail.com Received: by 10.60.63.167 with HTTP; Thu, 29 Mar 2012 11:02:12 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Mar 2012 11:02:12 -0700 X-Google-Sender-Auth: eGT6yR0Dd4IADjyiuZslrI3Zvpk Message-ID: Subject: Re: Proposal - Separate 2.x Git Branch From: Brian LeRoux To: callback-dev@incubator.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org > Because I had something COMPLETELY DIFFERENT IN MIND. I like that future. So much so I even prototyped it in 2010 in the orig proj named Cordova (just different semantics). I think we are of the same mind but I'm proposing a different path to get there. Or possibly not. To be clear: a master cli script was considered too ambitious for a 2.x goal back in Oct by myself and Dave. Rather than "one giant script to rule them all" we felt moving the orig Cordova platform scripts into the mainline of each platform project was a great starting point that still allows us to write a master script down the road. The master script could be ignorant of the details, just calling out to the sub platform scripts for the utilities desired. It puts the responsibility of the sub-commands in the project that cares about it, where it should be. Developers using only Cordova/Android can still work with just those local scripts without having to worry about competing platform detritus in their shell. Now with all that said, I am personally very into having a master script being a 2.x goal! I think Dave, Fil, Michael and Andrew would heartily agree. (We are tooling geeks tho.) To get there, we still need those sub commands solid, tested and documented. Consider too, just getting the sub commands working well and consistently across platforms is still a really big win for 2.x and makes writing that master script super trivial anyhow. (Also these scripts exist today for iOS, Android and BlackBerry.) > first 2.x, I suspect we'll then have to wait for 3.x, as the project/plug= in > structure will have to be settled, and whatever we do it 2.x prolly won't > be exactly what we need, and so we'll need to refactor things, AGAIN. The plugin package format is slated 2.x in the roadmap now. Will we refactor in the future? Without a doubt. We need to deal with that by communicating better with our community and documenting our releases better. > My understanding of where we're going is that Cordova becomes a "plugin" > and "web view" manager. Yes, and I'd like to point out to the readers of this thread at this point the conversation has diverged from CLI Tooling to Plugin Tooling. > All the existing batteries-included plugins will > at least removable from whatever we install, or maybe you get no plugins > with a default install. Maybe, I think installing just 3rd party plugins is a good start though. > But the plugins are a core part of our story. The whole theme of 2.x really. > So, I'd like a clearer definition of things like "cli tooling", and then = a > list of "things that must be in 2.x, we will not move these to the next > release". =A0That second list may be the empty list - nothing will hold u= p > thje 2.x release in . =A0That's fine. =A0Just trying to underst= and. For me the defn of cli tooling is whats in that wiki page under the title "Command Line Interface Tooling" and for plugins its under "PhoneGap Plugin Project". Yes, the detail is light and that is mostly due to us focusing on getting through CordovaJS, CordovaView and the great renaming. Perhaps now, we kick up a new thread about CLI Tooling and a separate one about Plugins? The good news here: we agree these are good goals for 1.7-2.x