Skip to Content

SAP delivers SAPUI5 / OpenUI5 with maintenance and innovation versions on several platforms and environments.

Recently we received customer feedback and understand the request to consume UI5 innovations not only on a quarterly basis, but earlier and in a way which fits better to the consumer’s schedule. With this approach we support agile projects on platforms like SAP Cloud Platform and also streamline SAP’s own continuous delivery process. UI5 introduces an increased delivery frequency with monthly releases after version 1.60. This enables you to consume new features sooner, while at the same time you can ensure stability with a maintenance version, just like you are doing today for your productive environments.

For this the version number will be increased by 1 for each version (instead of 2 as it is now): 1.60 -> 1.61 -> 1.62 -> …

Every month SAP releases a new version of UI5 for productive usage on SAP Cloud Platform via ui5.sap.com All these versions meet the same quality standard.

  • There is one Continuous Innovation version every month containing new innovations & features. Bugs in this version will be fixed in the next version.
  • Besides this regular approach for bug fixes, Continuous Innovation versions are patched in case show stoppers are reported.
  • There is one Maintenance Version per year. This version is recommended for productive / stable environments and is supplied with approx. bi-weekly patches (as needed). You might notice that here there is no change to the current maintenance strategy.

 

Picture: Cloud Versions and Patches

 

For SAP NetWeaver AS for ABAP there is also no change in delivering a new version every 6 months, see details in SAP note 221489

  • One Maintenance Version per year with an extended maintenance period.
  • One Innovation Version per year, containing the latest features. This version is maintained until the next version.

For details on this versioning and maintenance strategy please see the UI5 Demo Kit. The current versions according to this concept are listed in the SAPUI5 Versions Maintenance Status

What does this mean?

These monthly versions are fully qualified UI5 versions that can be used for productive scenarios on SAP Cloud Platform. This is not just about increasing the delivery frequency, there are several measures and process changes in SAP which ensure higher quality standards that are required for this approach. Also bug fixes are provided: in case of show stopper problems, there will be immediate patches to such an innovation version. For regular problems, the next standard UI5 version will contain the required fixes.

For onPremise usage, there is no change at all. On top of the mentioned maintenance release, there is a second UI5 version per year that will be released with the SP0 of the UI Extension Program / FES. This is going to be maintained for 6 months until the next stable version is available. Therefore there is no regression/reduction for any customer.

Regarding API changes: In case SAP potentially intends to change an API based on customer feedback, there will be special mechanisms like feature flags that customers specifically have to turn on to consume such an API. All other newly released APIs have the standard compatibility promise.

So what does this mean for you when consuming SAPUI5 or OpenUI5?

You already have the existing option to rely on a stable maintenance version. On top, you gain the option to consume new UI5 innovations and e.g. have access to the latest evolution of Fiori design for your projects.

 

Taste the difference, try fresh UI5 innovations every month!

To report this post you need to login first.

9 Comments

You must be Logged on to comment or reply to a post.

  1. Ethan Jewett

    Republishing from the OpenUI5 Slack with additional discussion:

    Moving closer to something recognizable as semantic versioning (good!), but still not (bad).

    Question: Why are we insisting on having a shared version number scheme? If the innovation versions are essentially betas, then why not publish them as betas outside of the maintenance release cycle?

    The way it is described here, you effectively don’t have an innovation version in the 1.60 and 1.72 release cycle because that is a maintenance version, which means that you will likely lose functionality from (for example) the 1.71 to 1.72 release because it is not maintenance-ready and then have it magically re-appear in the 1.73 release. It’s also endlessly confusing for customers and development teams who have a hard time understanding what should be used productively and what shouldn’t be, as making that determination requires consulting external documentation.

    If your innovation versions are really beta for the next maintenance version, then why not publish them as 1.72.0-beta.1.0, 1.72.0-beta.2.0? If you need to patch one, then 1.72.0-beta.1.1. Those are valid semantic versions. Alternatively, publish the innovation code-line as an entirely different library. Either of these options would squash the problematic case we see now where people are using the innovation code line productively without knowing any better because it is the default in WebIDE and because JS developers are trained to use the latest version number that appears to be non-beta.

     

    (0) 
    1. Michael Graf

      Hi Ethan,

      the innovation versions are not a beta or unstable release and can of course be used productively. They are basically our regular ongoing UI5 shipment – thus the version number is increasing directly with each new release. We just narrowed down the release cycle from 3 months to 1 months and thus the numbering slightly changed.

      The only major difference between innovation and maintenance versions is the lifecycle. A maintenance version will receive ongoing patches for bugfixes for roughly two years, while an innovation version will have a shorter lifetime and we recommend migrating to the next innovation version rather soon to receive further fixes after the next release is out.

      Feature-wise there is no difference as all releases are from the same codeline, feature are going to be shipped in innovation versions and in maintenance versions, depending on when they are ready to be published. But new features won’t be shipped in patches for the maintenance codeline. So if you want to consume the latest UI5 features, use the innovation version. If you care for the longer lifecycle and don’t need the brandnew features, maintenance version is the way to go.

      If you prefer a beta shipment (this is indeed not recommended for productive use), you can consume the OpenUI5 npm modules or the nightly build SDK. There we already have the unreleased 1.60.x versions available. Next week we will post a bit more information how to best consume OpenUI5.

      Hope that helps!

      Michael

      (1) 
      1. Ethan Jewett

        Hi Michael,

         

        Thanks for the response! It’s good to hear that the maintenance versions won’t lose functionality.

        Maybe you can correct me, as this feeling may just be due to my getting burned on earlier versions, but as someone who develops Fiori apps for Fiori Launchpad on the SAP_UI component, I don’t believe it is a good idea to use the innovation versions productively. This is because the delivery of UI5 is locked in to the maintenance version on that platform. We do now use the CDN delivery for most projects, but my impression has been that we should still stick to the same minor version as delivered with the SAP_UI component to avoid incompatibilities with the Launchpad components that still load from the local FES as well as backend services. Since I suspect the vast majority of external UI5 customers are in this same platform situation, if I am correct about the need to stick with the maintenance version, the message to use the innovation versions is sending them on the wrong path.

        I would love to hear that I am wrong about this, and if I am, I would love to see some clear guidance to this effect in a note that I can bring to my customers.

        The other issue with innovation versions is, of course, that in the past SAP has reserved the right to make API-breaking changes between minor versions. The 1-year maintenance window is just too short for a lot of customer development shops to react to these changes. Has this changed as well?

         

        Thanks,

        Ethan

        (0) 
        1. Helmut Tammen

          Hi Ethan,

          I agree with you according the use of SAPUI5 in FLP but believe it or not there are also customers who don’t use FLP. They develop standalone UI5 applications. Managers of those companies see nice new features and want to see them in their apps. The innovation versions offer the possibility to fulfill such requirements. If you name those versions “beta” nobody would use them in production and developers would rather use more dynamic frameworks than UI5 cause they would say SAP is a slow vendor with only a new release once a year.

          If you look at node.js they have a similar strategy. Their innovation versions (uneven version number) are released every 6 months. They release stable versions (even version number) once a year. Each stable version has an active phase of 18 months and a following maintenance phase of 12 months. That way they have a maximum of two stable version in active phase and a maximum of 3 versions in active or maintenance phase. This enables them to manage the releases with an affordable effort I guess.

          Even though I would like to see a SAPUI5 maintenance version more often I can understand the decision to release only once a year. So I think it’s good to have the innovation versions for impatient customers / developers. Nevertheless it’s up to us consultants to inform the customers about the drawbacks of those versions regarding support as well as more operation and test effort.

          Regards Helmut

          (2) 
  2. Wolfgang Röckelein

    Hi Mr Graef,

    thanks for the informatrions in this blog.

    What I am still missing is an fixed CDN URL for a maintenance versions which will automatically receives the security and bug fixes, i.e. as with https://openui5.hana.ondemand.com/resources/sap-ui-core.js for the innovation version.

    I mean something like https://openui5.hana.ondemand.com/1.52/resources/sap-ui-core.js which should always deliver the current 1.52.x maintenance version.

    Regards,

    Wolfgang Röckelein

    (1) 
    1. Oliver Graeff
      Post author

      Hello Mr. Röckelein,

      right, I understand. Regarding such a URL/setup which would automatically consume bug fixes we are somewhat reluctant. This means a customer would automatically experience such bug fixes in a productive environment. While this basically makes sense, we rather let the customer make an explicit decision about any changes to a productive environment.

      Thanks a lot,
      Oliver Graeff

      (0) 
      1. Tino Behrmann

        Why not providing both?

        1. If a customer wants the newest UI5 version with latest patch, then use this:

        https://openui5.hana.ondemand.com/resources/sap-ui-core.js

        2. If a customer wants a secific UI5 version with the latest patch, then use this:

        https://openui5.hana.ondemand.com/1.52/resources/sap-ui-core.js

        3. If a customer wants a secific UI5 version with a specific patch level, then use this:

        https://openui5.hana.ondemand.com/1.52.9/resources/sap-ui-core.js

         

        Regards,

        Tino

        (2) 

Leave a Reply