Daily Builds...

SinisterSoft

I'm new here from Corona, one thing they do that is pretty good are Daily Builds. These are basically an Edge build of Corona with the very latest developments. Daily builds are not supported and you might have to change code for the final build.

Is there any chance that GiderOS will introduce a daily build system?

gorkem

We talked about this several times with Atilim. I run across daily builds a lot in open source communities, especially with big projects having vast resources. In order to provide a daily build, we need a server farm, a build and continuous integration system (e.g Hudson or CruiseControl) that can build for multiple platforms using cross compilation and a combined versioning & bug reporting system with this CI platform (yes, I'd prefer every piece of this build system to work together).

In my opinion, there are some drawbacks to this approach in Gideros Studio case:

1. It's a huge work given the number of components to work with each other.
2. Currently we have a 6-10 weeks of release period, and we really focus on stability and performance. We personally do not want to break this perception.
3. There are really very few number of features (left) that a game developer cannot live without.
4. When someone asks for a new, critical feature, we always listen very carefully and try to prioritize it. A simple mobile game (excluding Zheng's cases) is developed in 1-2 months, and most of the time developers accept to wait this much time for a particular
feature.
5. [Joke] MikeHart hates it :-)

Therefore, honestly speaking, if we have some additional personal resources to govern a build system, then I'd go for it, but in the current situation, it's too hard to maintain it.

Görkem

evs

The thing I dislike about daily builds is that the mainstream builds can get neglected and left way behind (No $$$ L-) ). Take a look at you know what to see my point!

Just my tuppence worth

cheers

evs

avo

I think the current system works fine and is justified given Gorkems explanation. As long as we can see progress being made regularly it keeps everyone happy I think.

However this gives me a good chance as any to inquire when we might see the next release and what are the main things planned for it?

atilim

These will be definitely implemented at the next version:
- command line tools to export projects and control the player
- AsyncLoader class to load textures at background thread
- AlertBox and TextInput native UI classes (for all platforms)
- LuaFileSystem plugin

And most probably:
- In-app Billing for Android

Also there will be a couple of bugfixes and some small additions.

GregBUG

These will be definitely implemented at the next version:
- command line tools to export projects and control the player
- AsyncLoader class to load textures at background thread
- AlertBox and TextInput native UI classes (for all platforms)
- LuaFileSystem plugin

And most probably:
- In-app Billing for Android

Also there will be a couple of bugfixes and some small additions.

uuuuu... i love this man!!!

atilim

@GregBUG mutually

avo

exciting thanks atilim! is it too early to predict a date?

edit: just saw in another thread atilim says hopefully 1 month

evs

@atilim excellent stuff!!!

A tool to take a folder hierarchy and make it into a .gproj with all items and folders set up would be cool B-) Maybe just updating if the .gproj exists already


cheers

evs

atilim

@avo hopefully

@evs good idea. let me think about it.

glennbjr

Noooo. Sorry, I come from the beer sdk too and most daily builds are far to buggy for me. Each daily build seems to create more and different bugs. Please don't do daily builds :-q

Just my two cents >-

Nascode

Ah yes, daily build. In my experience, daily build is rather buggy, granted it comes without guarantee. I think Gideros have it's own way for releasing production ready SDK in specific interval (another sdk who released in specific interval is Marmalade)

SinisterSoft

No problem, the reason seems reasonable enough to me, if it doesn't take that long to build then how about a beta build (rather than a daily build) near completion. This would be useful to catch any bugs that might have crept in that you might not have been able to foresee.

Like the new features arriving next version btw.

If you can sneak it in then can I suggest one more feature to add? The OAuth 2 system is rapidly gaining popularity and an OAuth 2 client library would enable us to connect to Facebook, Twitter, and loads more online services without having to bother you to add them.

gorkem

@sinistersoft you can always create an account on bugs.giderosmobile.com and send your request there. Meanwhile, you can have a look at LuaOAuth - does it answer your needs?

SinisterSoft

@gorkem I'll do that tonight (off out in a sec), I've seen LuaOAuth before - but that is for OAuth 1.x, OAuth 2.x is a different beast altogether unfortunately.

nicholasclayg

This is from june...but.

I too came from Corona, but I would only release on the latest stable build. Daily builds are good and all, but I can only imagine the infrastructure that would take to do such a thing. I'm a datacenter architect by day and code games at night (wee!). I'd much rather the resources go into a stable product that works rather than "Daily build is released, oh crap don't use feature X it broke, and by the way this is broken too now, it will be fixed in the next release....oh wait it's fixed, but now it's not....". Soon as you start pouring resources into supporting that, then that means that you aren't working on the core platform or something is getting sacrificed somewhere. I could be off base on that, who knows I'm kinda new to this mobile thing.

That's been my experience from the Corona side. As a side note, this website is not as ehrmmm, functional (from a design perspective) and the API documentation could use a lot of examples of usage etc, however I'm willing to put up with it as just switching to Gideros increased my performance and not getting as many physics issues. Maybe that is due to more exposed box2d than Corona, I don't know I'm kind of new to coding (june 2011, never coded anything before that) but I can tell what works and what doesn't.

Oh yea, what was I talking about I think this is fine the way it is

ng

OZApps

my two bits...,
Daily builds are a strange thing. They are the required evil.

1. The Daily build is fluid and sussceptable to change as it is not finalised/fixed in stone.
2. It could entirely disappear from a release
3. It brings in expectations and then causes discontent when the expectations are not met

It is something like a comic, as a kid several years ago, I would wait for the newstand to have the new issue. But If I were to get a panel every so often and then find that those panels were not included or that story was omitted, it would not be nice.

On the other hand, the daily builds are like patch/fixes that address some of the issues that exist in the public release. So waiting in a vacuum till that was fixed can make a developer nervous. It is almost like the recent issue where the Player crashed when a TTFont was used.

With C*SDK, the issue is that there are so many releases, that after a while it is just not possible to download 80+ MB every time/day. Worse still is that while daily builds fix an issue, they also remove many other features. I had retained an older version of C*SDK for building for older Androids and iOS devices. Following public build 704b for Retina devices, backwards compatibility was broken.

In terms of Gideros, persoanlly I am happy to see the wishlist/buglist and hope that the features are ticked off that soon. @Atilim, you need to poach a few guys to join the Gideros dev team and get this jet speeding.

OZApps

@Atilim, I guess I did mention the same thing to you that @evs suggested, since .gproj is an XML document, it requires slightly more processing than just dumping the filenames in it. To separate the IDE from the player this would be important as .gproj is an important file in the whole process.

Can you have that if ther eis a gproj file then the assets/files are taken as described from the gproj file, otherwise all of the files in the current directory are added to a dynamic .gproj file. So if a new asset is added to the project, it is automatically included. The project settings can be moved to a config.lua file, which can be run when the player starts and have a default setting (if nothing is found). That way it can become a lot more flexible and be usable.