Proposal - Separate 2.x Git Branch

[Patrick Mueller <pm...@gmail.com>]

Discuss here, add questions to the wiki, etc:


http://wiki.apache.org/cordova/Proposal%202012%20Separate%202.x%20Git%20Branch

-- 
Patrick Mueller
http://muellerware.org

Re: Proposal - Separate 2.x Git Branch

[Filip Maj <fi...@adobe.com>]

... Not part of the apache dist? Why not? Those are essential for our
target audiences IMO

On 3/29/12 12:48 PM, "Drew Walters" <de...@gmail.com> wrote:

>Except that those aren't a part of the distribution package and `ant
>create-plugin` doesn't exist at all anymore ;-)
>
>On Thu, Mar 29, 2012 at 2:43 PM, Filip Maj <fi...@adobe.com> wrote:
>> The ant scripts are the start of CLI tooling for BlackBerry.
>>
>> "ant create <path to my project dir>"
>> "ant create-plugin <path to plugin>"
>>
>> Not as filled-in as the Android/iOS versions but they are there and we
>>can
>> get them the rest of the way with a little effort.
>>
>> On 3/29/12 11:15 AM, "Drew Walters" <de...@gmail.com> wrote:
>>
>>>> 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.)
>>>
>>>Can someone point me at the BlackBerry versions of these.  I'm a bit
>>>confused what is being discussed here.
>>>
>>>On Thu, Mar 29, 2012 at 1:02 PM, Brian LeRoux <b...@brian.io> wrote:
>>>>> 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/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.
>>>>
>>>> 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".  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.
>>>>
>>>> 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
>>

Re: Proposal - Separate 2.x Git Branch

[Drew Walters <de...@gmail.com>]

Except that those aren't a part of the distribution package and `ant
create-plugin` doesn't exist at all anymore ;-)

On Thu, Mar 29, 2012 at 2:43 PM, Filip Maj <fi...@adobe.com> wrote:
> The ant scripts are the start of CLI tooling for BlackBerry.
>
> "ant create <path to my project dir>"
> "ant create-plugin <path to plugin>"
>
> Not as filled-in as the Android/iOS versions but they are there and we can
> get them the rest of the way with a little effort.
>
> On 3/29/12 11:15 AM, "Drew Walters" <de...@gmail.com> wrote:
>
>>> 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.)
>>
>>Can someone point me at the BlackBerry versions of these.  I'm a bit
>>confused what is being discussed here.
>>
>>On Thu, Mar 29, 2012 at 1:02 PM, Brian LeRoux <b...@brian.io> wrote:
>>>> 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/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.
>>>
>>> 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".  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.
>>>
>>> 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
>

Re: Proposal - Separate 2.x Git Branch

[Filip Maj <fi...@adobe.com>]

The ant scripts are the start of CLI tooling for BlackBerry.

"ant create <path to my project dir>"
"ant create-plugin <path to plugin>"

Not as filled-in as the Android/iOS versions but they are there and we can
get them the rest of the way with a little effort.

On 3/29/12 11:15 AM, "Drew Walters" <de...@gmail.com> wrote:

>> 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.)
>
>Can someone point me at the BlackBerry versions of these.  I'm a bit
>confused what is being discussed here.
>
>On Thu, Mar 29, 2012 at 1:02 PM, Brian LeRoux <b...@brian.io> wrote:
>>> 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/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.
>>
>> 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".  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.
>>
>> 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

Re: Proposal - Separate 2.x Git Branch

[Brian LeRoux <b...@brian.io>]

ya no worries, not really there for any platform: yet

its been prototyped, proven in production dev workflow at nitobi,
ready for prime time treatment in 1.7

heck, maybe even a master script for 2.x now

On Thu, Mar 29, 2012 at 12:59 PM, Drew Walters <de...@gmail.com> wrote:
> At one point the BlackBerry distribution (coho release output?) was
> changed to simply provide a sample project folder that the end user
> can make a copy of.  I think the change was made for simplicity.  The
> 'ant create' functionality is still available but only if you clone
> the repo.
>
> Just wanted to clarify that the BB side of this stuff is not there.
>
> On Thu, Mar 29, 2012 at 2:52 PM, Brian LeRoux <b...@brian.io> wrote:
>> mike brooks wrote em up in ant scripts -- dunno if they still work!
>> thats a goal for 1.7
>>
>> On Thu, Mar 29, 2012 at 11:15 AM, Drew Walters <de...@gmail.com> wrote:
>>>> 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.)
>>>
>>> Can someone point me at the BlackBerry versions of these.  I'm a bit
>>> confused what is being discussed here.
>>>
>>> On Thu, Mar 29, 2012 at 1:02 PM, Brian LeRoux <b...@brian.io> wrote:
>>>>> 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/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.
>>>>
>>>> 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".  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.
>>>>
>>>> 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

Re: Proposal - Separate 2.x Git Branch

[Drew Walters <de...@gmail.com>]

At one point the BlackBerry distribution (coho release output?) was
changed to simply provide a sample project folder that the end user
can make a copy of.  I think the change was made for simplicity.  The
'ant create' functionality is still available but only if you clone
the repo.

Just wanted to clarify that the BB side of this stuff is not there.

On Thu, Mar 29, 2012 at 2:52 PM, Brian LeRoux <b...@brian.io> wrote:
> mike brooks wrote em up in ant scripts -- dunno if they still work!
> thats a goal for 1.7
>
> On Thu, Mar 29, 2012 at 11:15 AM, Drew Walters <de...@gmail.com> wrote:
>>> 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.)
>>
>> Can someone point me at the BlackBerry versions of these.  I'm a bit
>> confused what is being discussed here.
>>
>> On Thu, Mar 29, 2012 at 1:02 PM, Brian LeRoux <b...@brian.io> wrote:
>>>> 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/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.
>>>
>>> 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".  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.
>>>
>>> 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

Re: Proposal - Separate 2.x Git Branch

[Brian LeRoux <b...@brian.io>]

mike brooks wrote em up in ant scripts -- dunno if they still work!
thats a goal for 1.7

On Thu, Mar 29, 2012 at 11:15 AM, Drew Walters <de...@gmail.com> wrote:
>> 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.)
>
> Can someone point me at the BlackBerry versions of these.  I'm a bit
> confused what is being discussed here.
>
> On Thu, Mar 29, 2012 at 1:02 PM, Brian LeRoux <b...@brian.io> wrote:
>>> 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/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.
>>
>> 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".  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.
>>
>> 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

Re: Proposal - Separate 2.x Git Branch

[Drew Walters <de...@gmail.com>]

> 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.)

Can someone point me at the BlackBerry versions of these.  I'm a bit
confused what is being discussed here.

On Thu, Mar 29, 2012 at 1:02 PM, Brian LeRoux <b...@brian.io> wrote:
>> 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/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.
>
> 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".  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.
>
> 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

Re: Proposal - Separate 2.x Git Branch

[Patrick Mueller <pm...@gmail.com>]

On Thu, Mar 29, 2012 at 14:02, Brian LeRoux <b...@brian.io> wrote:
>
> Perhaps now, we kick up a new thread about CLI Tooling and a separate
> one about Plugins?
>

will do

-- 
Patrick Mueller
http://muellerware.org

Re: Proposal - Separate 2.x Git Branch

[Brian LeRoux <b...@brian.io>]

> 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/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.

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".  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.

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

Re: Proposal - Separate 2.x Git Branch

[Patrick Mueller <pm...@gmail.com>]

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

Re: Proposal - Separate 2.x Git Branch

[Brian LeRoux <b...@brian.io>]

> The problem is - I don't understand the scope of the 2.x work.

Yeah, this is what Fil and I both were trying to get at in the other thread.


> Maybe I'm missing something.  Is there more detail than this?
>
>    http://wiki.apache.org/cordova/RoadmapProjects

No, those are the high level goals. The idea would be to take those
goals and turn them into issues for 1.7 ...and beyond. As the release
comes. There is more detail on each sorta proj if you scroll down.


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


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


> in 2.(x+1)!" just because we had to ship on a certain date.  I want to ship
> a kick ass 2.x release, and I honestly don't really care WHEN it happens.

Agree. And if we ONLY spent the next 4 months just fixing bugs,
hardening, and cleaning up the docs 2.x kicks ass in July.

2.x summary: plugins, vastly improved tooling, weinre on nodejs,
CordovaJS, CordovaView, moving to Apache, and adding Windows Phone 7,
Qt, and possibly Tizen.

Not bad.

> Maybe July is do-able!  Help me understand the scope!

CordovaView on Android may be a breakable scene but I don't think it
has to be. Java gives us plenty of tools for shimming in backwards
compat. There's probably a whole book of design patterns and an XML
schema for just that. ;9

Otherwise the story is tests, docs, tooling, and lots of bugs
squashed. Nothing destructive imo.

Re: Proposal - Separate 2.x Git Branch

[Patrick Mueller <pm...@gmail.com>]

On Wed, Mar 28, 2012 at 20:34, Brian LeRoux <b...@brian.io> wrote:

> Moreso july is somewhat arbitrarily around the OSCON which is when we
> all happen to be in Portland. Its a good excuse for a summertime beer
> with friends. =)
>

Oh, come on.  We don't really need MORE excuses for drinking beer, do we?
:-)


> Really, I like to think what we're doing is 'rolling releases' with
> one overarching goal and bunch of mini goals to get there.

...
> Rather than releasing too early, or too late, just release on a
> regular schedule. Thats the basic premise.
>

You're preaching to the choir on 'rolling releases'.  Been doing it for
years, successfully - usually 6 weeks working out better than 4.
 Especially if the devs are also doing some amount of support for the
previous releases (and we always are).

I like that the 1.x work is on this kind of schedule.  And I'd like to do
this with 2.x as well.

The problem is - I don't understand the scope of the 2.x work.  Maybe I'm
missing something.  Is there more detail than this?

    http://wiki.apache.org/cordova/RoadmapProjects

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.

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.

I've also done date-based releases, plenty of times.  "Thou shall ship on
xx/yy/zzzz".  No problem, as long as the customer understands that there's
a risk that function may need to be cut.  Cutting quality is never an
option, and extending the date is supposedly not an option, so when push
comes to shove, function gets dropped.  Customer gets to decide.  Sometimes
they decide (implicitly) to cut quality, by saying the date stays AND no
function gets dropped SO now you're in super crunch mode.

But I don't want to drop function or quality for 2.x.  I don't want to have
have the 2.x release where we say - "but wait till you see what we give you
in 2.(x+1)!" just because we had to ship on a certain date.  I want to ship
a kick ass 2.x release, and I honestly don't really care WHEN it happens.

Maybe July is do-able!  Help me understand the scope!

BTW, none of this has anything to do with moving the 2.x work to a
different stream than 1.x, which is what this thread is for :-)  Other than
my belief that working on 1.x and 2.x in the same stream will draw the 2.x
work out even longer than we need to.

-- 
Patrick Mueller
http://muellerware.org

Re: Proposal - Separate 2.x Git Branch

[Brian LeRoux <b...@brian.io>]

Moreso july is somewhat arbitrarily around the OSCON which is when we
all happen to be in Portland. Its a good excuse for a summertime beer
with friends. =)

Really, I like to think what we're doing is 'rolling releases' with
one overarching goal and bunch of mini goals to get there. Do a little
Google around on 'release train'. It what we've been doing though some
might argue we haven't spent enough time 'hardening'. I'd disagree
given our bugs are around things like 'need better docs' and not
epic-fail-code-no-compile type business. *shrug

Its what ubuntu, firefox, chrome and others do. I'm not saying do
stuff b/c everyone else is; but its a far better model than 'release
when its done' aka 'release every 2 years or so' or worse. Working on
a blog post to describe my thoughts on the benefits vs the drawbacks
of the approach.

Rather than releasing too early, or too late, just release on a
regular schedule. Thats the basic premise.


On Wed, Mar 28, 2012 at 4:57 PM, Filip Maj <fi...@adobe.com> wrote:
>
>
> On 3/28/12 4:35 PM, "Patrick Mueller" <pm...@gmail.com> wrote:
>
>>On Wed, Mar 28, 2012 at 19:17, Filip Maj <fi...@adobe.com> wrote:
>>
>>> One point release per month: 1.7 end of April, 1.8 end of May, 1.9 end
>>>of
>>> June, 2.0 end of July. Exactly one year after we released 1.0 (although
>>> the math doesn't quite add up there :P)
>>
>>
>>So the release schedule is based around astronomical units????
>
> Arbitrary astronomical units, yes.
>
> I'm OK with lining it up with the lunar calendar if that's what you're
> suggesting.
>
>>
>>--
>>Patrick Mueller
>>http://muellerware.org
>

Re: Proposal - Separate 2.x Git Branch

[Filip Maj <fi...@adobe.com>]

On 3/28/12 4:35 PM, "Patrick Mueller" <pm...@gmail.com> wrote:

>On Wed, Mar 28, 2012 at 19:17, Filip Maj <fi...@adobe.com> wrote:
>
>> One point release per month: 1.7 end of April, 1.8 end of May, 1.9 end
>>of
>> June, 2.0 end of July. Exactly one year after we released 1.0 (although
>> the math doesn't quite add up there :P)
>
>
>So the release schedule is based around astronomical units????

Arbitrary astronomical units, yes.

I'm OK with lining it up with the lunar calendar if that's what you're
suggesting.

>
>-- 
>Patrick Mueller
>http://muellerware.org

Re: Proposal - Separate 2.x Git Branch

[Patrick Mueller <pm...@gmail.com>]

On Wed, Mar 28, 2012 at 19:17, Filip Maj <fi...@adobe.com> wrote:

> One point release per month: 1.7 end of April, 1.8 end of May, 1.9 end of
> June, 2.0 end of July. Exactly one year after we released 1.0 (although
> the math doesn't quite add up there :P)


So the release schedule is based around astronomical units????

-- 
Patrick Mueller
http://muellerware.org

Re: Proposal - Separate 2.x Git Branch

[Filip Maj <fi...@adobe.com>]

One point release per month: 1.7 end of April, 1.8 end of May, 1.9 end of
June, 2.0 end of July. Exactly one year after we released 1.0 (although
the math doesn't quite add up there :P)

On 3/28/12 4:11 PM, "Patrick Mueller" <pm...@gmail.com> wrote:

>On Wed, Mar 28, 2012 at 18:57, Brian LeRoux <b...@brian.io> wrote:.
>
>> are you guys thinking we *do not* ship 2.x in the summer of july?
>
>
>Just speaking for myself here (as always!).
>
>No idea. Maybe. Maybe not.
>
>How did you calculate the July date?
>
>-- 
>Patrick Mueller
>http://muellerware.org

Re: Proposal - Separate 2.x Git Branch

[Patrick Mueller <pm...@gmail.com>]

On Wed, Mar 28, 2012 at 18:57, Brian LeRoux <b...@brian.io> wrote:.

> are you guys thinking we *do not* ship 2.x in the summer of july?


Just speaking for myself here (as always!).

No idea. Maybe. Maybe not.

How did you calculate the July date?

-- 
Patrick Mueller
http://muellerware.org

Re: Proposal - Separate 2.x Git Branch

[Brian LeRoux <b...@brian.io>]

are you guys thinking we *do not* ship 2.x in the summer of july?

On Wed, Mar 28, 2012 at 3:45 PM, Patrick Mueller <pm...@gmail.com> wrote:
> Discuss here, add questions to the wiki, etc:
>
>
> http://wiki.apache.org/cordova/Proposal%202012%20Separate%202.x%20Git%20Branch
>
> --
> Patrick Mueller
> http://muellerware.org