incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Mueller <pmue...@gmail.com>
Subject Re: Proposal - Separate 2.x Git Branch
Date Thu, 29 Mar 2012 17:18:45 GMT
On Thu, Mar 29, 2012 at 12:14, Brian LeRoux <b@brian.io> wrote:

> > Show me the man pages of the cli tooling, for instance, so I can get a
> > sense of what the effort/complexity for it is going to be.
>
> We do have cli tooling for all the major platforms however. Maybe man
> pages are all that needs doing for iOS, Android and BlackBerry. For
> Windows Phone the tooling needs writing.
>

You mean, this, for iOS, is the "cli tooling"?

    https://github.com/apache/incubator-cordova-ios/tree/master/bin

Because I had something COMPLETELY DIFFERENT IN MIND.

- single 'cordova' command, installable via npm (npm install http:/
dist.apache.org/whatever.tar.gz)
- lots of subcommands; think 'git'
- subcommand: init/create - initialize/create a new Cordova project
- subcommand: addPlatform - set to handle a new platform in the project
- subcommand: addPluginRepo - add a new plugin repo in the project
- subcommand: addPlugin - install a new plugin repo from a plugin repo in
the project
- subcommand: <remove variants of the add subcommands>
- subcommand: build [platform] - build the app for the platform (default:
all platforms)
- subcommand: debug platform
- subcommand: yadda-yadda whatever

That's kick-ass.  That's what I want in 2.x.  If we can't do this in the
first 2.x, I suspect we'll then have to wait for 3.x, as the project/plugin
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.  Tell
people how to restructure their plugins, AGAIN.  Or tell people, plugins
are still not official, AGAIN. Now we're in 2013-land.  Sigh.

In my mind, the tooling ends up having a lot of impacts on how we structure
at least the "binary" archives of our releases, but likely the actual
source structure as well, so that we can easily develop plugins without
having to jump through the kinds of build-install hoops we have to, today.

I don't see us on a good, stable, maybe-future-safe direction, until we
have this tooling working.  Or at least limping quite well.

My understanding of where we're going is that Cordova becomes a "plugin"
and "web view" manager.  All the existing batteries-included plugins will
at least removable from whatever we install, or maybe you get no plugins
with a default install.  But the plugins are a core part of our story.  If
we haven't provided a way to add/remove plugins, from the command line -
and that includes the native bits! - then we haven't arrived at the stable,
maybe-future-safe nirvana for Cordova.  As far as I'm concerned, we might
as well just keep on trucking on the 1.x stream.

> If I don't know the scope of the work, I can't really estimate how many
> > 'rolling releases' we're going to have, and so can't estimate the final
> > release date.
>
> The scope has nothing to do with the release; if something doesn't fit
> in, is not baked enough, we move to the next release. And lets be
> clear: the issue w/ 1.5 was not instability: it was documentation.
>

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".  That second list may be the empty list - nothing will hold up
thje 2.x release in <whenever>.  That's fine.  Just trying to understand.

-- 
Patrick Mueller
http://muellerware.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message