Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of brian.leroux@gmail.com
 designates 209.85.161.175 as permitted sender)
MIME-Version: 1.0
Sender: brian.leroux@gmail.com
In-Reply-To: 
 <CAO_65gwWYW_XVXbqDFXz-zJnqQOYRLziF6vY0SHn3Uu3jypP_w@mail.gmail.com>
References: 
 <CACAoQH3G6OkGt+pLFs31gnYBos8HV_ET_e2QN-=eRevkJ=ciFA@mail.gmail.com>
	<CAM1AYQBPwvSQWTj2=8nwYa2CYrGCqexU-k3uWB3MPn5HTv_Hog@mail.gmail.com>
	<CAO_65gwWYW_XVXbqDFXz-zJnqQOYRLziF6vY0SHn3Uu3jypP_w@mail.gmail.com>
Date: Mon, 26 Mar 2012 09:08:27 -0700
Message-ID: 
 <CADVgkyPOJSrECcQY+=dWn43Y_MFuJwz-LRE_Uy3NMkWzPMGxPA@mail.gmail.com>
Subject: Re: endless refactoring of plugins until "Cordova 2.x"
From: Brian LeRoux <b@brian.io>
To: callback-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On one hand I buy into this to shield from change and allow ppl time
to migrate. On the other, thats the point of a point release to me. To
make the migration incremental so that 2.x does NOT break all the
things and is viewed as a fucked up release.

This will mean 2.x work stays in a branch and has to be constantly
rebased which may be really painful for implementors.

Either way, separation of bugs from new-ness smells pragmatic; and I
know we share the same goals here of plugins for everything. Before we
go ahead w/ the assumption everything from here is drastic can we
first outline exactly what happens next?

- Removal of undocumented but in use globals.
- Consolidation of tooling for plugin package validation,
installation, and removal.
- Refactor of native code into discreet packages across platforms into
atomic units called plugins. Eg. cordova-plugin-geolocation
- Refacotor coho to allow for composing a release of particular plugins.
- Document correct procedure for generating a plugin.
- Automate plugin discovery ala npm/cpan/rubygems/pypi/etc.

What am I missing? Lets update the roadmap so we can allow ppl to stay
bleeding towards 2.x and be on the same page for whats happening next.

Agree, plugins are in a hard way right now but this is all for the
better for them!


On Mon, Mar 26, 2012 at 7:11 AM, Drew Walters <deedubbu@gmail.com> wrote:
> +1 to 2.0 development stream. =A0Too many structural level changes are
> happening between releases right now.
>
> On Mon, Mar 26, 2012 at 9:07 AM, Simon MacDonald
> <simon.macdonald@gmail.com> wrote:
>> I would love to see this too stream approach moving forward with Cordova
>> until the 2.0 release.
>>
>> Simon Mac Donald
>> http://hi.im/simonmacdonald
>>
>>
>> On Mon, Mar 26, 2012 at 10:00 AM, Patrick Mueller <pmuellr@gmail.com> wr=
ote:
>>
>>> see:
>>> =A0 =A0https://issues.apache.org/jira/browse/CB-298
>>> =A0 =A0"DEPRECATE and then remove "plugins" and "PhoneGap" global objec=
ts from
>>> JavaScript implementation"
>>>
>>> So, at this point, it looks like anyone with plugins who wants to follo=
w
>>> the Cordova releases will be in a constant state of refactoring to
>>> accommodate each new point release. =A0That is so painful.
>>>
>>> Add to this, our release cycle is 4 weeks, so we realistically have a
>>> couple of weeks to implement refactorings, such as described in the
>>> referenced bug. =A0Which means we don't have a lot of time to capture
>>> feedback from those refactorings before they become "new API".
>>>
>>> This really isn't great.
>>>
>>> I think at this point, I'd like to freeze the 1.x "API", and have a
>>> separate stream of development for 2.x.
>>>
>>> Downside:
>>>
>>> - separate streams of development
>>>
>>> Upside:
>>>
>>> - easier to stabilize 1.x level API
>>> - longer-lived streams of development for 2.x
>>> - most folks will only have to refactor their plugins once, from 1.x to
>>> 2.0, instead of 1.5 -> 1.6, 1.6 -> 1.7, ...
>>>
>>> --
>>> Patrick Mueller
>>> http://muellerware.org
>>>