incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: How to manage upgrading your projects for new "Callback" releases?
Date Fri, 28 Oct 2011 22:47:24 GMT
Thanks for bringing this up here Matt --- this is a really important
topic. I think the dream would be as simple as update a binary and the
js file but we have introduced other project artifacts in the recent
days (such as plugin config, config.xml and whitelisting). All these
artifacts and things like project generation/debug/release is still
very different platform to platform and it is our goal to correct
that. This problem only manifests on projects that attempt more than
one platform too, eh.

Might finally be time to start talking about what a software project
using phonegap should look like. A package format would allow for
automation of these things instead of hunting around the latest IDE
update like a goof.

Cordova is a good prototype of this sort of approach. It does make
assumptions and enforces structure as a result. As a benefit you get a
tonne of automation. We started moving some of that automation into
the respective PhoneGap/* repos under ./bin (and under a ./phonegap
folder in generated projects).

I think its reasonable for us to think about getting this sort of
thing in the roadmap.


On Fri, Oct 28, 2011 at 11:26 AM, Matt Rogish <matt.rogish@gmail.com> wrote:
> Hi everyone,
>
> When PhoneGap - ahem, Callback - releases a new version how do you upgrade your existing
projects? On Android, we find that most of the time we just need to drop in the jar/js. On
iOS, though, it's a lot more complicated; the docs suggest you are to rebuild your entire
project which is really painful and we'd like to avoid it if possible.
>
> However, occasionally some releases have necessitated an upgrade (sometime in the early
0.x releases the iOS went from embedded in the project to a system lib; Xcode4 junk, etc.)
but it's very difficult to tell sometimes by reading the commit logs how to know if you have
to rebuild a given project.
>
> I'd propose only Major revision bumps trigger a rebuild (a riff off of http://semver.org/)
but that may not be possible; versioning these different projects are hard, I agree, especially
since a bump may only require *some* projects to be rebuilt and not others (Android tools
new release, for example, requires a change in droidgap default project).
>
> Is something a bit better documented possible/doable? It's just really frustrating to
not know if we need to rebuild all of our projects or not, and it makes it really difficult
to test if we are slogging through full build regression suites every time we bump a minor
version of PhoneGap because it may have changed something in iPad 4.3 project files etc.We
can look at the diff in github, but that seems suboptimal as it's not entirely obvious if
anything changed that requires a rebuild or just some tweaking.
>
> We have good JS app test coverage but once PhoneGap & individual project build files
get in the mix the automated scripts are much harder to have tightened up, unfortunately.
>
> I dunno. Any advice/thoughts/guidance? Is there something we're missing?
>
> Thanks,
>
> --
> Matt Rogish
>
>

Mime
View raw message