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.
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.
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.
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
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
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
Minor bug fixes in display rendering (UI)
Refactoring: Removed transient fields that are not used.
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?
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.
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
Does this help Heike?