Switching libGDX Versions
libGDX’s Gradle based projects make it very easy to switch between libGDX versions. In general you’ll be interested in two types of libGDX builds:
- Release builds: these are considered stable. You can see the available release versions on Maven Central.
- Nightly builds: also known as SNAPSHOT builds in Maven lingo. These are cutting edge versions of libGDX that are built on every change to the source repository. Snapshot builds also have a version number of the form
x.y.z-SNAPSHOT, e.g.1.9.10-SNAPSHOT. You can find the latest SNAPSHOT version string here.
Your Gradle based project makes it very easy to switch between releases and nightly builds. Open up the build.gradle file in the root of your project, and locate the following line:
gdxVersion = "1.5.2"
The version you see will most certainly be higher than 1.5.2. Once you’ve located that string, you can simply change it to the latest release (or an older release) or to the current SNAPSHOT version. You may also have to update other modules and dependencies in that same section of the build.gradle file, based on the versions listing. Once edited, save the build.gradle file.
The next step is dependent on your IDE:
- Eclipse: Select all your projects in the package explorer, right click, then click
Gradle -> Refresh All. This will download the libGDX version you specified inbuild.gradleand wire up the JAR files with your projects correctly. - IntelliJ IDEA / Android Studio: will usually detect that your
build.gradlehas been updated and show a refresh button. Just click it and IDEA will update libGDX to the version you specified inbuild.gradle. Go into the Gradle tasks panel/tool view and click the refresh button. Running a task like ‘builddependents’ also tends to do this. - Netbeans: in the “Projects” view, right-click the top-most project node and select “Reload Project”. All sub-projects will also be reloaded with the new files.
- Command Line: invoking any of the tasks will usually check for changes in dependency versions and redownload anything that changed.
Replacing additional files
You may need to replace additional files for some releases. They are listed here:
Update to release 1.9.13+
Since version 1.9.13, breaking changes and corresponding migration steps are explicitly mentioned in our changelogs. Take a look at them here.
Update to release 1.9.12
- HTML: You can delete the soundmanager files for HTML Project and the references in index.html
- HTML: You should update code in HTMLLauncher according to setup template
Update to release 1.9.6
- Replace soundmanager files for HTML project, otherwise Web Application might not start. See #2246.
Gradle Versions Plugin
In the spirit of the Maven Versions Plugin, the Gradle Versions Plugin provides a simple dependencyUpdates task to determine which dependencies have updates.
Updating Gradle Itself
You may also want to update your Gradle version.
Gradle Wrapper
Essentially, the Gradle Wrapper (./gradlew) is a script that invokes a declared version of Gradle, downloading it beforehand if necessary. It is the recommended way to execute any Gradle build, because it does away with complex setups and allows any developer to get a project up and running in no time. Alternatively, you can use a system Gradle installation.
To update the Gradle Wrapper version that is embedded (and stored in your repository), you can run the following command,
./gradlew wrapper --gradle-version #{GRADLE_VERSION}
where #{GRADLE_VERSION} is your preferred Gradle version. We advise you to use the one specified here for our setup tool.
As an alternative, you can specify a Gradle distribution by URL (take a look here for official distributions):
./gradlew wrapper --gradle-distribution-url #{GRADLE_DISTRIBUTION_URL}
Additional Steps
Since Gradle updates often introduce breaking changes, you might need to take additional steps to get your project running again after an update. Usually, we recommend just recreating your project structure with the setup tool and then copying over your dependencies and code. Alternatively, you can take a look at the changes we made to the setup tool’s example project here.