ya this is really great: would love to see as Contributer section too
On Fri, Mar 15, 2013 at 4:20 AM, Michael Brooks
wrote:
> Reads very well, nice work Braden!
>
> I was going to mention adding the creation of a topic branch for
> completeness, but Ian, Max, and you have already hashed that out
Ya do that. Or jump in their IRC and ask around. Likely they'll tell
you to file an issue.
On Thu, Mar 14, 2013 at 10:25 PM, Herm Wong wrote:
> Do I need to log another Infra issue to get it done?
>
>> Date: Thu, 14 Mar 2013 14:22:46 -0700
>> Subject: Re: cordova-firefoxos repo has been created
>
Yea, this isn't pretty. Agree w/ Anis to cross the bridge when we get there.
Also agree w/ Fil's idea that dependencies are ok but a plugin only
gets loaded once and if a dep requires a different version then we
should fail noisily.
In a perfect world, that will be enough info for the developer t
FYI, on the DOAP files used to generate
http://projects.apache.org/projects/cordova.html I updated the list of versions
hosted on apache.org/dist (it previously listed 2.3 as "latest", I added 2.4
and 2.5).
@stevesgill, do you have a release checklist somewhere that this step could be
added?
It feels like we are trying to solve something that has been solved a thousand
times before:
http://en.wikipedia.org/wiki/List_of_software_package_management_systems
Do we really need to be building something from scratch, or can we reuse
something that already exists?
-- Marcel Kinard
The original intention, circa maybe six months ago, was to use npm for the
discovery and installation. Our use case doesn't match with npm, though. It
makes certain assumptions about the way versions are handled, in
particular, that we can't accept, because of the global plugin namespace
problem me
Michael, very nice presentation!
-- Marcel
On Mar 14, 2013, at 11:20 PM, Michael Brooks wrote:
> Reads very well, nice work Braden!
>
> I was going to mention adding the creation of a topic branch for
> completeness, but Ian, Max, and you have already hashed that out.
>
> I would vote to crea
On Mar 14, 2013, at 11:02 PM, Michael Brooks wrote:
> +1 for switching the deprecation window from time to release. Michal summed
> it up perfectly.
Agreed.
>
> It's worth reflecting on Tommy and Simon's input. The deprecation window is
> there to give users adequate warning that breakage is
We will definitely care as well as we move directly on top of Cordova. Cordova
is being adopted more and more as a platform that others will build on. A
certain level of predictability and stability in a platform is certainly
appreciated at least. ;)
We will be heavily invested in the plug-
Ya, that prototype was just a bunch of new file copying code and only
really would have only used npm for its publish and registry
functions. Much would be the same if we 'reused' another solution.
Cordova is a very unique project, and a bespoke tool is going to be
much easier to maintain rather th
To Tommy-Carlos' point, I believe plugins (or the plugin interface) will
unlikely break when we get closer to 3.0. Reason is: if the plugin
interface breaks then everything will break :-D We certainly don't want
that.
On Fri, Mar 15, 2013 at 7:25 AM, Ken Wallis wrote:
> We will definitely care
>
https://googledrive.com/host/0B8sLcyOAEX-XUHAxNXhISE5rTTg/guide_contributing_index.md.html
I like this, it's clean, reads well, and covers a lot of information for
those wanting to contribute to the project without any prior git knowledge.
Michael's PhoneGap Day talk was also excellent; amongst
Becky wrote:
> Well, I know that people do use find a lot and are frequently tripped up by
> it.
> They get confused over the fact that the fields array is the list of
> fields that are returned AND are searched.
> Most people expect all of the contact information returned and they think that
> th
Just updated uncrustify from .59 -> .60
The good news is it no longer breaks the new Obj-C primitives (@{}, @[]),
and it does a better job at ternary ifs.
The bad news is that it changes a significant amount of code. Not great if
we have the code blame changing due to style updates.
I think I'd
Might as well take the hit now. no need for code blame - blame usually is
with the usual suspects (starting with myself of course) ;)
On Fri, Mar 15, 2013 at 10:35 AM, Andrew Grieve wrote:
> Just updated uncrustify from .59 -> .60
>
> The good news is it no longer breaks the new Obj-C primitives
FYI, nodejitsu (where i host the medic/ci server) were kind enough to
reimburse the costs of hosting, and its free moving forward. woot! thanks
nodejitsu!
-- Forwarded message --
From: Julian Duque
Date: Thu, Mar 14, 2013 at 11:46 PM
Subject: Re: [Nodejitsu] Request free/oss accou
Hey Marcel,
I usually follow the cutting release article on our wiki. I somehow
overlooked the DOAP file update. I am adding a new section to coho that
commits the releases once they are generated. I will see if I can automate
the updating of the DOAP file in that section too.
AUTOMATE ALL THE TH
Hey
Since we're working towards making the core plugins installable and
uninstallable, I want to go ahead and move all the plugins to a core
directory so that their Java namespace will be
org.apache.cordova.core. This means that adding and removing will be
less painful for scripts since they shou
Do we provide any way to update config. Xml as all of the paths to the
plugins will be incorrect? Possibly an update script?
Simon
On Mar 15, 2013 5:01 PM, "Joe Bowser" wrote:
> Hey
>
> Since we're working towards making the core plugins installable and
> uninstallable, I want to go ahead and mo
Honestly, config.xml is a file that is going to be edited by users
now, so the last thing that I want to do is get yet another script
involved, since it could really screw up their config.xml and make
things even worse. I think we'd be better off giving them a heads up
when we release this and let
Providing an upgrade path is still something we need to consider.
So yes, an upgrade guide that says "change the values of your plugins from
x to y" is doable. As well as a script that does a global search/replace.
Not rocket science.
On 3/15/13 2:19 PM, "Joe Bowser" wrote:
>Honestly, config.xm
On Fri, Mar 15, 2013 at 2:22 PM, Filip Maj wrote:
> Providing an upgrade path is still something we need to consider.
>
> So yes, an upgrade guide that says "change the values of your plugins from
> x to y" is doable. As well as a script that does a global search/replace.
> Not rocket science.
I
+1 Star?
On Thu, Mar 14, 2013 at 10:40 AM, Steven Gill wrote:
> It has been done
>
> On Thu, Mar 14, 2013 at 8:44 AM, Braden Shepherdson >wrote:
>
> > I have initialized a dossier and require enstellation.
> >
> >
> > On Thu, Mar 14, 2013 at 11:27 AM, Andrew Grieve > >wrote:
> >
> > > Profile
What is it that needs to change in the config.xml as far as plugins are
concerned ? I am hoping they will keep the same name and namespace when
they get updated, right ? The only things that should change when plugins
get updated is the native/javascript code and maybe dependencies (but
that's anot
On Fri, Mar 15, 2013 at 2:41 PM, Anis KADRI wrote:
> What is it that needs to change in the config.xml as far as plugins are
> concerned ? I am hoping they will keep the same name and namespace when
> they get updated, right ?
That's if they get updated. When they get installed, the entry has to
Related to the specific naming and namespaces:
http://wiki.apache.org/cordova/Core%20Plugin%20Name%20Proposal
I don't care on the namespace label. However, I would rather not have to
change it more than over the next few releases. Every time the namespace
of a plugin changes, it requires a longe
So to answer your question it is an automatic process taken care of by
plugman on installation/uninstallation.
On Fri, Mar 15, 2013 at 2:48 PM, Joe Bowser wrote:
> On Fri, Mar 15, 2013 at 2:41 PM, Anis KADRI wrote:
> > What is it that needs to change in the config.xml as far as plugins are
> >
It sounds to me like the consensus is to leave them where they are for
now. I'll keep my changes out of master for the time being.
On Fri, Mar 15, 2013 at 2:56 PM, Anis KADRI wrote:
> So to answer your question it is an automatic process taken care of by
> plugman on installation/uninstallation.
Yeah, I mean, I think you can keep whatever namespace we use CURRENTLY,
until that becomes a real issue / we actually split it out. Since this is
all just an exercise to see how far our plugin spec and the tooling can
go, and what's missing, the specific answer to the namespace question
isn't super
Ah thanks for clarifying that.
I'm not sure how I can alleviate the ui thread any more than I am
currently. It is already doing the bare minimum amount of work on the
there. Right now the only work done on the ui thread is
view.capturePicture() which is the recommended thread for doing that work
As someone who had to manually ignore uncrustify hooks to get around the
literals issue, I vote +1.
On Fri, Mar 15, 2013 at 1:52 PM, Shazron wrote:
> Might as well take the hit now. no need for code blame - blame usually is
> with the usual suspects (starting with myself of course) ;)
>
>
> On
31 matches
Mail list logo
