Beta Release:  tranSMART 19.0 Release (May 2020)

These pages contain information on the current status of development of tranSMART 19.0 beta.

Current Release:  tranSMART 16.3 Release (Aug 2018)

These pages contain information on the 16.3 release of tranSMART.

Further Development:  tranSMART 22.0 Roadmap (late 2022)

These pages contain information on the proposals for the further development of tranSMART.

tranSMART Roadmap

This wiki entry describes the tranSMART Foundation’s release policies for the tranSMART Platform.

Release planning is coordinated through the tranSMART Foundation’s JIRA database.   For ideas about what you might contribute to the platform and roadmap, please see the “Project Suggestions” and “How to Contribute” pages.

Release Numbering

The official tranSMART Foundation tranSMART releases are numbered in the form of releaseyear.number.  That is, for the first release of 2016, the release number is 16.1.  The second release for 2016 is 16.2, etc.  Releases are planned every 6 months.

Release Process

The tranSMART platform is on an overlapping six month development / six month release cycle, which will result in a new release every six months.  Thus, the Foundation has an active development cycle AND an active release cycle running at all times.  For a release, a branch date is selected for the release

Previous tranSMART Releases

tranSMART 16.2 Release (Feb 2017)

These pages contain information on the current status of development of tranSMART 16.2.

tranSMART Release 16.1 (aka v1.2.5) - Release 1st Half of 2016

Release Process Improvements

        • Digitally signed release materials

          • PGP signature for official Foundation release


        • a new, single line install script for Ubuntu/Postgres


        • bug fixes and general enhancements


        • bug fixes and general enhancements


        • updated to work with both Oracle and Postgres

        • Updated functionality

tranSMART v1.2.4 - (released February, 2015)


  • Added minor improvement: customized spring security messages.

  • Added security measure: temporarily lock account after some failed login trials (configurable)

  • Bug fixes: for user groups modification, for cross-trials nodes, for VCF calculations in export

  • Minor extensions to support (optional) XNAT plugin

  • Added security measure: user has to enter password for import instead of storing it

  • Refactor: improved import process and messaging


Bug Fixes

  • Fixed RCommandsStep RConnection string encoding

  • Fixed bug in Survival Analysis (multiple censor variables)

  • Fixed bug – Clear categorical and numerical bins when clearing high dimensional nodes

  • Fixed bug in Frequency Plot

  • Fixed bug: KMeans heatmap-function should not cluster

  • Fixed bug: Vanilla heatmap should not cluster.

  • Fixed Bug: Export log-intensity if zscore calculation on the fly is checked

Improvements, UI tweaks, and Refactoring

  • Added warning note to log10 option in scatter plot

  • Remove correlation-by selection from gui

  • Reword error message for ACGH validation

  • Added validation for high dimensional data nodes and data type

  • Prune concept to shortest unique leaf

  • Computation of Z-Score: Categorical variable detection

  • Added check and error message for missing chromosome/region data

  • Added validation for numerical variables before binning (heatmap)

  • Changed legend and scaling for heatmap plots

  • BoxPlot: Allow multiple variables for binning

  • Refactor: Made error catching across heatmap analyses consistent


  • Refactor: Better naming for sort index

  • Added sorting to tags mapping


  • Added “two region support”

  • Added a method to get all concepts by data-type.

  • Added a method to get all HD nodes for a patient.


  • Added support for new API methods

  • Bug fix in composite id

  • Bug fix for data export

  • Added test for VFC calculations


  • Refactoring: whitespace cleanup; clearer function names; better logging

  • Added removeTag javascript function (for editing)

  • Minor bug fixes in display rendering (UI)


  • Refactoring: Removed transient fields that are not used.

  • No labels


  1. In the slide with the title "Development and Release Roadmap" - with the time line - what is the correspondence between the "old" version numbers and the "new" version numbers. That is, 1.2.5 maps to 16.2? 1.3 maps to 16.2?

  2. Terry,

    The roadmap defines a series of projects - these projects are referred to by the projected release timing.  Thus, the 16.1 project is moving toward a release in the first half of 2016, while the 16.2 project is moving toward a release in the second have of 2016.  We are working on an overlapping development and release cycle, such that we are always running a development project AND a release project, but they are for two different releases.

    In terms of naming the releases, we have seen a lot of confusion in the community regarding version numbers.  Thus, we are moving to a discussion where each official tranSMART Foundation release is referred to by its project number (e.g., 16.1), and a unique name.  If others build releases based upon these, they should use a different naming convention, so that their release is not confused with a tranSMART Foundation official release.  We will also be implementing a release signing process, so that official Foundation releases will be uniquely identified with a digital signature that verifies the source of that release being from the Foundation.  We have continued to use the 'old' release terminology along with the new terminology, so that people can see the relationship between the two.




  3. To see project names in the roadmap is nice - but will not help a lot. The delivery of each project this is interesting. In this case it should be the transmart release/version I think

  4. Does this help Heike?