Platform Versioning

One of the goals of the new ITAG Release Process is to ensure and maintain an accurate ITAG Platform version on each of the containers. This will allow every project to quickly know exactly what is running in each environment.  It will also enable projects to specify minimum platform requirements during the build process. To understand the concept of a versioned platform it helps to think about JEE (J2EE). JEE is a collection of individually versioned APIs/libraries.   When the collection is taken as a whole it forms a platform on which robust applications can be designed and built.  This platform can be assigned a version representing the unique collection of its individual elements, for instance JEE 1.0.  The individual APIs/libraries that compose JEE are themselves versioned (e.g.  JavaMail 1.0.1, Servlet 2.2, JTA 1.0 etc.). If any of the individual libraries in the platform is updated and re-incorporated into JEE, the platform version is updated as well.  For example if JEE 1.0 contains Servlet 2.2 and then sometime later Servlet 2.3 is released and re-incorporated, the JEE platform version would become JEE  1.1. The ITAG Release Process takes a similar approach to the APIs/libraries placed on the server classpath.  In ITAG, the collection of JARs on the server classpath defines a platform on which our applications are designed and built.  We can assign this collection of classpath JARs a platform version representing a unique collection of its elements.  When any of the JARs on the server’s classpath change, the platform changes and its version number changes.

Hypothetical example:

ITAG_1.0 ITAG_1.1 ITAG_2.0
jlink2.jar (1.12) jlink2.jar (1.13) jlink2.jar (1.13)
mail.jar (1.1) mail.jar (1.1) mail.jar (1.1)
esb.jar (1.0) esb.jar (1.0) esb.jar (1.0)
apol.jar (1.0) apol.jar (1.0.1) apol.jar (1.0.1)
springmvc.jar (3.0)