incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Rogish <>
Subject How to manage upgrading your projects for new "Callback" releases?
Date Fri, 28 Oct 2011 18:26:24 GMT
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
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? 


Matt Rogish

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