This page uses release 100 as a version example. We recommend always using the latest versions of code and data.
Ensembl Versioning Scheme
Each Ensembl release has an integer version number associated with it which is used to identify the correct versions of the API, web code and databases that make up that release. The idea is that components with the same release version should work together - i.e. any web site built with 'version 100' API and web code, and 'version 100' databases should work correctly.
The BioMart code has its own versioning scheme, since it is independent of the Ensembl code - see the BioMart website for information on using the code separately, e.g. with the MartJ Java interface.
Previous releases of Ensembl from at least the last five years are archived to support long running data analysis projects. Other archive!s, for example those providing significant releases of human annotation such as that on the NCBI36 assembly", are maintained for longer. For more information about the Archive! sites and past assemblies, see the list of current archives.
Ensembl Code Versioning
For the APIs and the web code, a git branch (essentially a named snapshot of the code) is made for each release and named with the release version number. The Perl API and web code can be checked out of git with the branch "release/versionnumber", e.g. release/100.
Ensembl Data Versioning
The Ensembl database names have the format:
<species><database type><release number><assembly version>
As an example, the name of the Human Core database for the Ensembl 95 release on the GRCh38 assembly would be:
A letter suffix to the data version indicates a change in data without a change in assembly; e.g. a new gene build.
BioMart will branch less frequently than Ensembl, and the release number bears no relation to that of Ensembl.