Müller, R. D., Cannon, J., Qin, X., Watson, R. J., Gurnis, M., Williams, S., Pfaffelmoser, T., Seton, M., Russell, S. H. J. ,Zahirovic S. (2018). GPlates: Building a virtual Earth through deep time. Geochemistry, Geophysics, Geosystems, 19, 2243-2261.

Mather, B. R., Müller, R. D., Zahirovic, S., Cannon, J., Chin, M., Ilano, L., Wright, N. M., Alfonso, C., Williams, S., Tetley, M., Merdith, A. (2023) Deep time spatio-temporal data analysis using pyGPlates with PlateTectonicTools and GPlately. Geoscience Data Journal, 00, 1-8.

GPlates is a plate tectonics program with a range of features for visualising and manipulating plate tectonic reconstructions and associated data through geological time.

PyGPlates is a Python package enabling fine-grained access to the core tectonic plate reconstruction functionality in GPlates.

Both GPlates and pyGPlates are available in this repository.

The initial release of GPlates, version 0.5 Beta, debuted on October 30, 2003. Since its inception, GPlates has evolved into a robust software suite encompassing desktop application, Python libraries, web service and application, and mobile app, offering a comprehensive range of functionalities.

GPlates is developed by an international team of scientists and software developers.

For more information please visit the GPlates website.

The documentation includes:

• the GPlates user manual to learn about specific GPlates functionality (such as tools, menus and dialogs),
• GPlates tutorials to learn how to use GPlates in research-oriented workflows,
• pyGPlates library documentation covering installation, sample code and a detailed API reference for pyGPlates,
• pyGPlates tutorials in the form of Jupyter Notebooks that analyse and visualise real-world data using pyGPlates.

There is also a GPlates online forum for the users, developers and researchers to discuss topics related to GPlates and pyGPlates.

GPlates can be installed on Windows, macOS (Intel and Silicon) and Ubuntu via ready-to-use binary packages. These packages also include GPlates-compatible geodata.

PyGPlates can be installed using conda or pip. Please see the installation instructions in the pyGPlates documentation.

Note: The rest of this document is only for those wishing to compile GPlates or pyGPlates from source. Most users will not need to, since GPlates is available as ready-to-use binary packages and pyGPlates can be installed using conda or pip (see above).

The source code can be compiled on Windows, macOS and Linux.

Both GPlates and pyGPlates are compiled from this one repository (and from the same branch) - which of the two is selected when configuring the build.

Instructions for installing the dependencies and compiling GPlates/pyGPlates can be found in the source code, in the files:

• BUILD-Linux.md (on Linux)
• BUILD-macOS.md (on macOS)
• BUILD-Windows.md (on Windows)

GPlates and pyGPlates are free software (also known as open-source software), licensed for distribution under the GNU General Public License (GPL) version 2 (see COPYING).

• Boost 1.69 or above (1.70 or above if cmake >= 3.30)
• CGAL 4.12 or above
• CMake 3.22 or above
• GDAL 2.0 or above
• GLEW
• PROJ 6 or above
• Python 3.8 or above
• Qt 6.x recommended (5.15 also supported)
• Qwt 6.0.1 or above (preferably 6.1 or above)

There is one permanent development branch, plus one permanent branch per release series:

• gplates is the development branch (and the default branch). Both GPlates and pyGPlates are developed here. Check it out to compile the latest development snapshot of either product.
• release/gplates-<major>.<minor> and release/pygplates-<major>.<minor> (eg, release/gplates-2.6 and release/pygplates-1.1) are the release series branches. Each is created from the development branch when the first release in that series is prepared, and every release in the series is then tagged on it - the release candidates, the release itself and any later patch releases - so its tip is always the newest release in that series.

To compile a public release, check out its tag (eg, GPlates-2.5 or PyGPlates-1.0.0) - the releases are listed on the Releases page - or, for the newest release in a series, check out the series branch.

All other branches are short-lived, created from one of the permanent branches and deleted once merged back:

• feature/<name> and fix/<name> branches, for developing a new feature or fixing a bug, are created from (and merged back into) the development branch,
• patch branches, for a fix to a version that has already been released, are created from (and merged back into) a release series branch.

Note: This is no longer gitflow. It is the branching model that QGIS, GDAL, CGAL, LLVM and CPython use: development happens on the default branch, and releases are tagged on permanent per-series branches. There is no separate 'production' branch and no hotfix branch (a patch release is simply a further commit on the release series branch). The reasoning, and what was considered instead, is in docs/design/versioning/README.md.

Note: The development branch will be renamed main in a later change.

Versions are derived from git rather than written by hand. cmake/modules/VersionRelease.cmake names the release each product is heading towards (eg, 2.6.0 for GPlates and 1.1.0 for pyGPlates), and the build appends a development number counted from the git history. So a development build of GPlates has a version like 2.6.0-47 and of pyGPlates 1.1.0.dev46, while a build standing on a release tag has exactly the release version.

Note: Counting needs the whole git history, so a shallow clone (git clone --depth ...) is refused. And a source archive with no git repository at all needs the version supplied, as described at the top of cmake/modules/VersionFromGit.cmake.

How the version is derived, how to see what a checkout resolves to, how to find the commit that a version was built from, and how a fork can keep its own version numbers, are all described in docs/design/versioning/README.md.