Upcoming Product Updates for Rhythmyx
The Percussion Engineering team has been hard at work wrapping up the 7.3.1 service release for Rhythmyx. The central feature of this release is an update to the version of Java that Rhythmyx is deployed on. The move to Java 1.8 is the first in a series of platform updates to keep Rhythmyx current and up to date with current technology and information security requirements.
2015 Q4.1 - 7.3 Patch
Scheduled to ship this week (10-11-2015) , this patch will focus on updating the Java Applet for compatibility with the latest Java update. The latest Java update changed the manner that Image resources are processed causing the Applet to fail to refresh or "lock-up" if icons were setup for a Content Type.
7.3.1 Service Release
Scheduled to ship in mid Q4, this is a cumulative service release for Rhythmyx 7.3.1. The central feature of this release is an update to the version of Java that Rhythmyx is deployed with from version 1.6 to version 1.8 of Java. This is a significant platform change that has required extensive development and testing.
The 7.3.1 release is the first of a series of service releases that are planned for Rhythmyx as we update and modernize platform components. Due to the scope of change that Service Releases include, Service Releases will always require an upgrade. Service Releases allow us to ship bug fixes or enhancements that require database schema changes or updates to core system components (like Java).
Changes to Patch Frequency and Scope
Historically Rhythmyx Patches have included a series of bug fixes and have generally shipped on a quarterly basis. All Rhythmyx Patches are cumulative including any defects or enhancements released through previous patches.
As customer's transition off of the Java based Edit Live Rich Text editor to the Java-free TinyMCE Rich Text editor, and our Engineering team continues to work on platform updates. We expect a more frequent number of interim patches with smaller sets of fixes included in each Patch.
This approach will enable us to more rapidly respond to customer issues related to the new or updated features, and will also limit the scope of what is affected in a given Patch. Limiting Patch scope reduces complexity, and reduces the risk of introducing regressions in a given Patch.
We plan and perform work on a two week sprint basis, and plan to be able to ship a Patch at the end of each sprint on an as needed basis.