[ANN] mergExt releases for iOS 9.2

Monte Goulding monte at appisle.net
Fri Feb 12 00:24:18 EST 2016

> On 11 Feb 2016, at 9:26 PM, Ben Rubinstein <benr_mc at cogapp.com> wrote:
> Noooo.... -1!
> On 10/02/2016 15:41, Mike Kerner wrote:
>> The other thing that would be nice would be to maybe have the new versions
>> not be marked with the version number.  I realize that can be dangerous,
>> but for every app, I have to go into Copy Files for every external and
>> point to the new one.  When I forget (especially if I haven't done a new
>> build in a while), that means at least one "whoops" build.
> I strongly disagree. I'd much rather have control and know exactly which version I'm using with each application. Admittedly in this case the changes may be mostly invisible tweaks to accomodate iOS differences, but stuff always needs testing, and there can easily be unexpected effects.
> I'd much rather have to do a small amount of deliberate work upfront when I want to switch to a new version, than have to spend more time diagnosing mysterious behaviour when I did it without meaning to. That's especially going to happen to an app where I haven't done a new build in a while.
> My feature request, on the contrary, would be for for Monte to add a standard "mergVersion" function to every external in the suite, so that we can always verify exactly what we've got (and so that app error reports, for example, can include this information by default).
> My AUS$ 0.02,

At this stage what I’m considering is an additional large archive containing all externals so you can still download individual files. At the moment I scp a large archive over to my server and run a script on it to deploy everything into the right spot. It shouldn’t be overly complicated to extract each of the external archives and then archive the lot at the end of that script.

A version function is probably feasible (I need to be able to automate changing the version number from by external builder stack. It’s probably not something I’ll get to in the very short term though.



More information about the use-livecode mailing list