We’ll go 1.0 next weekend!

libGDX 1.0

Just a heads-up, we are planning on going 1.0 next weekend. This release will not have any significant new features, but indicate a general maturity that we think we’ve arrived at. With the arrival of our Gradle based project-setup we can no longer afford having users work off of the nightlies for months between releases. From 1.0 onwards we’ll have bi-weekly releases, not necessarily coupled to any massive feature updates. This will allow you to work off of a frozen and up-to-date release. Currently, if you work off the nightlies, you have to store that nightly version on your end.

We’ll consider semantic versioning for our next releases. However, i do believe that it’s not a 100% fit for us. We’ll stay at major version 1 for the foreseeable future. We’ll increase the minor version on API changes, and the patch version for bug fix releases. This may mean we’d arrive at something like 1.2.10 at some point (meaning we created 10 bug fix releases without API changes :)).

With the 1.0 release we’ll also remove support for the gdx-setup-ui that generated Eclipse projects. Maintaining two things that do the same is always a bad idea. Our Gradle project generator is really nice now, the workflows in the different IDEs work pretty well, and the general experience is just better. We still have a few things to iron out, but we believe this can be done until next weekend.

I’m not sure i can do something special for 1.0, so please don’t expect anything :)

Libgdx updates to RoboVM 0.0.11, featuring new CocoaTouch bindings!

Niklas Therning of RoboVM fame send us a tasty pull request a few days ago that updates our RoboVM backend to the latest RoboVM version. I held off merging this PR until today when Niklas released RoboVM 0.0.11. The new CocoaTouch bindings, exposing iOS APIs to you, are now under a new package called org.robovm.apple. This means that your RoboVM starter classes need to be adapted a tiny little bit!

This:

package com.badlogic.gdx.tests;
 
import org.robovm.cocoatouch.foundation.NSAutoreleasePool;
import org.robovm.cocoatouch.uikit.UIApplication;
 
import com.badlogic.gdx.backends.iosrobovm.IOSApplication;
import com.badlogic.gdx.backends.iosrobovm.IOSApplicationConfiguration;
 
public class IOSRobovmTests extends IOSApplication.Delegate {
 
	@Override
	protected IOSApplication createApplication() {
		IOSApplicationConfiguration config = new IOSApplicationConfiguration();
		return new IOSApplication(new BulletTestCollection(), config);
	}
 
	public static void main(String[] argv) {
		NSAutoreleasePool pool = new NSAutoreleasePool();
		UIApplication.main(argv, null, IOSRobovmTests.class);		
		pool.drain();
	}
}

Becomes this:

package com.badlogic.gdx.tests;
 
import org.robovm.apple.foundation.NSAutoreleasePool;
import org.robovm.apple.uikit.UIApplication;
 
import com.badlogic.gdx.backends.iosrobovm.IOSApplication;
import com.badlogic.gdx.backends.iosrobovm.IOSApplicationConfiguration;
 
public class IOSRobovmTests extends IOSApplication.Delegate {	
	@Override
	protected IOSApplication createApplication() {
		IOSApplicationConfiguration config = new IOSApplicationConfiguration();
		return new IOSApplication(new BulletTestCollection(), config);
	}
 
	public static void main(String[] argv) {
		NSAutoreleasePool pool = new NSAutoreleasePool();
		UIApplication.main(argv, null, IOSRobovmTests.class);		
		pool.close();
	}
}

Both IOSApplication and NSAutoreleasePool have to be imported from the new package. NSAutoreleasePool#drain() has now become NSAutoReleasePool#close().

I also updated our Gradle templates to use the latest Gradle RoboVM plugin (0.0.6) and our Maven POMs to depend on the latest RoboVM version in Maven Central. Give it an hour or two to distribute into the nightlies, build on our build server sponsored by our awesome community via Patreon!