Most components of GT5 are incremental updates (numerous bug fixes and new features) over their GT4 counter-parts (e.g. GridFTP, RLS, MyProxy, GSI-OpenSSH). Some components of GT4 are not included in GT5 (e.g. GT4 Java Core, WS-GRAM4, RFT), to be replaced by new software under development (e.g. Crux, Globus.org Service) […] GT4.x releases will continue to be maintained and supported at least through the end of 2010. New users should immediately adopt 5.0.0. Existing users are encouraged to begin evaluating and migrating to GT5.

via

From a message sent by Ian Foster in October 2009:

• there have been long struggles and confusion over the GRAM2 vs. GRAM4 components. We have resolved these problems by re-investing in, fixing, and enhancing GRAM2. This new version, called GRAM5, is fully backward compatible with GRAM2 (with two minor exceptions: no support for MPICH-G/MPIG job rendezvous; and GRAM5 stages out stdout/err at the end of the job rather than streaming them out while the job runs), but solves its scalability issues and adds numerous frequently requested features. […] We will continue to support GRAM4 at least through December 2010 (perhaps longer, depending upon demand and funding), but have begun to assist GRAM4 users in migrating to GRAM5. […]

 

• the Reliable File Transfer (RFT) service has been of considerable interest to many Globus users, but in practice has suffered from difficulties in both use and operation. We have decided to replace the RFT functionality with a new Globus.org service: an online hosted service (i.e., Software-as-a-Service), to provide higher-level, end-to-end Grid capabilities, targeted to end users, as well as Grid builders looking for more complete solutions to build upon. Initial functionality of Globus.org will focus on replacing and enhancing the RFT functionality of reliable, high-performance, fire-and-forget data transfer, but over time will grow to include more “collective layer” functionality (as described in the “Anatomy of the Grid” paper 1]). […]

 

• GT4 Java Core is based heavily on obsolete technology (Apache Axis 1.x) and standards (WSRF), yet nonetheless continues to provide tremendous value-add to Web Services-based Grid builders, particularly in the area of security and stateful resource management. With the urging of, and in partnership with, some of our large Java Core users such as the caGrid team at Ohio State University, we have begun the Globus Crux effort to update our Java Web Services stack to newer technologies (e.g., Apache CXF), while preserving and enhancing our core value-add security capabilities as a plug-in to CXF and allowing for WSRF protocol compatibility. […]

 

• While MDS is applicable to a broad range of monitoring and discovery tasks, in practice its predominant use has been to build service registries/catalogs for TeraGrid, caBIG, and BIRN, with limited adoption for systems monitoring in a few other communities. Since MDS4 is intimately intertwined with GT4 Java Core, it would require a substantial reimplementation effort to update it to Crux.  Meanwhile, the state of monitoring tools has evolved considerably since MDS4 was first conceived, with the widespread adoption of highly capable, open source monitoring tools such as Nagios. Therefore we have begun work on a more focused effort to design and implement next generation service registry capabilities using Crux, which we are calling our Integrated Information Services (IIS) effort.  This IIS effort is still in the requirements gathering phase, with no releases planned until sometime in 2010.  We recommend that monitoring needs be met using other tools such as Nagios.

 

• Globus Toolkit version 5.2, targeted for Q1 2010, will focus on repackaging the GT5 components into independent component releases that leverage OS-native packaging approaches (e.g., RPM), with assistance from other groups (e.g., KnowARC) who have already blazed this trail. Subsequent GT releases in the remainder of 2010 will focus primarily on usability and reliability, along with features required by Globus.org. The repackaging effort will not impact backward compatibility with GT 5.0.  We expect GT 5.2 clients and services to be fully compatible with GT 5.0.