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.216.182 as permitted sender)
MIME-Version: 1.0
Sender: brian.leroux@gmail.com
In-Reply-To: <BD43667308C845AEBE00E9D3A031A466@gmail.com>
References: <BD43667308C845AEBE00E9D3A031A466@gmail.com>
Date: Fri, 28 Oct 2011 15:47:24 -0700
Message-ID: 
 <CADVgkyPJ++nR9F31vDDn_EjK8vh=GtA-25hzsyYdXVRtrGoZ2A@mail.gmail.com>
Subject: Re: How to manage upgrading your projects for new "Callback"
 releases?
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

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 upgrad=
e 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; t=
he docs suggest you are to rebuild your entire project which is really pain=
ful and we'd like to avoid it if possible.
>
> However, occasionally some releases have necessitated an upgrade (sometim=
e 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 ht=
tp://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 exam=
ple, requires a change in droidgap default project).
>
> Is something a bit better documented possible/doable? It's just really fr=
ustrating 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 i=
t may have changed something in iPad 4.3 project files etc.We can look at t=
he diff in github, but that seems suboptimal as it's not entirely obvious i=
f 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 ti=
ghtened up, unfortunately.
>
> I dunno. Any advice/thoughts/guidance? Is there something we're missing?
>
> Thanks,
>
> --
> Matt Rogish
>
>