Versioning policy

For a better way to understand the importance and the number and/or the quality of changes in each release - so that you can easily decide if you would like to upgrade the recent version - have you here our versioning policy.

When versioning the gUSE releases, we have 3 indices.

The first index represents generations. The current first index is 3, i.e., this is the third generation of P-GRADE portals. The 1st generation was never put into production, that was the version we learnt how to develop such complex gateway frameworks. The 2nd generation was what we called P-GRADE portal. This 3rd generation has also distinguishing name: gUSE/WS-PGRADE where WS-PGRADE notes the user interface and gUSE is the name of the high level service architecture (middleware) that contains the services needed to support WS-PGRADE.

The second index is increased if a major new functionality is introduced to the gateway framework. For example, index 4 was introduced when the DCI Bridge service was used first time in gUSE/WS-PGRADE. That was a major achievement since after that release adding new DCIs to gUSE became much easier than before. Index 5 was introduced when the integration with CloudBroker completed and as a result gUSE/WS-PGRADE users could access clouds. Recently, we introduced index 6 since the access to the new Data Avenue service became available (release 3.6.0).

The third index is used to note releases that introduce either new functionalities (but not as important as in case of the second index), or significant bug fixes, or simply to upgrade the gateway framework to be able to work together with an upgraded underlying service. For example, the current 3.6.1 release introduced the breakpoint technology at workflow level and upgraded the graph editor to be able to work together with the latest Java 7 version.

What are the implications of this versioning policy for you?

  1. You do not have to upgrade your production gateway all the time to the new releases. For example, if the new release contains functionalities or bug fixes that are not significant for your user community it makes no sense to upgrade your production gateway.
  2. It is worth first trying the new release only on your development gateway and if you are happy with the new release and it contains new features, bug fixes or underlying service upgrades that are important for your community, then it is recommended to upgrade your production gateway, too.