savingStandalone message

[Dave Kilroy]

Hi all

Ali I would find it really useful if we could set a build number for iOS builds inside the plist file where I’m using the 'external test’ functionality in TestFlight

I normally use my own way of setting and recording build numbers - and I’m happy to carry on doing do. But where there’s a problem is that there is currently no way to indicate to iTunesConnect what an app’s build number is as a separate value to the app’s version number (see http://quality.livecode.com/show_bug.cgi?id=14163 <http://quality.livecode.com/show_bug.cgi?id=14163>) - this means we can’t upload incremented binaries of the same version number to iTunesConnect for rapid deployment via TestFlight, and must instead upload an incremented version and then wait around three days for it to exit ‘Beta review'

So, if you are making changes to the standalone builder and including an option for build number could you bear TestFlight in mind?

Kind regards

Dave 



> Thanks for the feedback Paul. How is your build number increment 
> implemented? 
> 
> On Tue, Nov 15, 2016 at 1:18 PM Paul Dupuis <[hidden email] <http://runtime-revolution.278305.n4.nabble.com/user/SendEmail.jtp?type=node&node=4710301&i=0>> wrote: 
> 
> > I make use of the savingStandalone message in a few projects. Generally, 
> > I would prefer a single message regardless of the number of platforms I 
> > am building for. For ecample, I set a incremental "build' number on 
> > savingStandalone and I would want that build number to be the same for 
> > all platforms built for. If the message was sent for each platform I 
> > suspect I could come up with some what to still do this, but the code 
> > complexity would increase for a relatively simple task. 
> > 
> > It would seem to me that if you are looking for platform specific 
> > actions to modify the stack(s) used in each platform build, then ideally 
> > you would want a set of platform specific messages. i.e 
> > 
> > savingStandaloneForWindows 
> > savingStandaloneForOSX 
> > savingStandaloneForiOS 
> > savingStandaloneForAndroid 
> > savingStandaloneForHTML5 
> > ... 
> > 
> > Or something like that. That way if you only meed to make a specific 
> > scripted stack modification for Android, you only need to handle that 
> > specific message. 
> > 
> > 
> > On 11/15/2016 4:45 AM, Ali Lloyd wrote: 
> > > Hi all, 
> > > 
> > > Various tweaks to the standalone builder seem to have broken the way the 
> > > savingStandalone message is supposed to work 
> > > http://quality.livecode.com/show_bug.cgi?id=18778 <http://quality.livecode.com/show_bug.cgi?id=18778>
> > > 
> > > I have submitted a pull request that fixes it - the only wrinkle might be 
> > > that it reintroduces the following bug: 
> > > http://quality.livecode.com/show_bug.cgi?id=18364 <http://quality.livecode.com/show_bug.cgi?id=18364>, namely that the 
> > > savingStandalone message gets sent for each build platform. 
> > > 
> > > Now, my personal view is that that is how it should work, provided the 
> > > stack state is restored before building for the next platform. It allows 
> > a 
> > > more fine-grained build step where, if we added suitable parameters to 
> > the 
> > > message, you could for example ensure substacks with 
> > platform/architecture 
> > > specific resources were not included in the standalones where they are 
> > > irrelevant. 
> > > 
> > > My question to you is the same as I asked Lyn Teyla in the above report: 
> > > 
> > > Would the following behavior be a problem for your use case, and if so 
> > why? 
> > > 
> > > store stack state (*) 
> > > repeat for each target architecture 
> > >    dispatch saving standalone message 
> > >    modify stack for per-arch settings 
> > >    deploy stack 
> > >    restore to state in (*) 
> > >    dispatch standalone saved message 
> > > end repeat 
> > > _______________________________________________ 
> > > use-livecode mailing list 
> > > [hidden email] <http://runtime-revolution.278305.n4.nabble.com/user/SendEmail.jtp?type=node&node=4710301&i=1> 
> > > Please visit this url to subscribe, unsubscribe and manage your 
> > subscription preferences: 
> > > http://lists.runrev.com/mailman/listinfo/use-livecode <http://lists.runrev.com/mailman/listinfo/use-livecode>
> > > 
> > 
> > 
> > _______________________________________________ 
> > use-livecode mailing list 
> > [hidden email] <http://runtime-revolution.278305.n4.nabble.com/user/SendEmail.jtp?type=node&node=4710301&i=2> 
> > Please visit this url to subscribe, unsubscribe and manage your 
> > subscription preferences: 
> > http://lists.runrev.com/mailman/listinfo/use-livecode <http://lists.runrev.com/mailman/listinfo/use-livecode>
> >