Fresh UI5 innovations every month

[OliverGraeff]

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 long-term 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 a new 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, the versions are patched in case show stoppers are reported.


• There is one long-term 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 version per year, containing the latest features. This version is maintained until the next version.


• One long-term maintenance version per year with an extended maintenance period.

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 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 long-term 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!

(Updated terminology on 18. Jan 2019 for clarification)

[former_member321811]

Hi Oliver,

Could you tell us when OData V4 will be fully supported in SAPUI5?

Thanks,

Pierre

[OliverGraeff]

Hi Pierre,

the current state of planning is available in the SAPUI5 Roadmap: https://www.sap.com/roadmaps -> SAPUI5

Cheers,
Oliver

[esjewett]

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.

 

[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

[esjewett]

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

[htammen]

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

[WRoeckelein]

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

[OliverGraeff]

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

[Tino]

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

[StephanHeinberg]

Dear Oliver,

We only install SPS (Support Package Stacks) in our ERP with embedded frontend server.

How can I make sure, I never get an innovation release in my system?

We experienced quite a gambling. NetWeaver SPS Release schedule was not synced with UI5 release schedule.

Thanks,

Stephan

[ssimsekler]

Hello

Asked this in many places with no satisfactory answer: Is it OK to use SAP CDN in the bootstrap for pointing to the SAPUI5 library resources for the applications that are hosted on SAP Gateway? What are the possible problems this may cause?

I know this needs to be a separate question and I created one but did not get a satisfactory answer there either:

https://answers.sap.com/questions/682516/sapui5-library-upgrade-on-sap-gateway.html

Kind Regards

[Oliver_S]

Hi Stephan, you can see the planned SAP_UI SP schedules here .

Make sure you take an SAP Fiori Front-end Server minimum SPS which contains the maintenance version of SAPUI5. See the respective release notes. SPS00 contains always an innovation version so far.

Higher SPS or SAPUI5 patches of the FES version will only contain higher maintenance versions.

See also:

https://blogs.sap.com/2017/12/06/sap-fiori-front-end-server-in-a-nutshell/

(Links to FES Release Note available under “Additional Information”)

[StephanHeinberg]

Thanks, I got it. Would it not be easier if the NetWeaver SPS manager would make that choice for me?

I assume nobody wants innovations releases in NetWeaver, especially now with the monthly release.

Now I have to manage a NW Sub SPS.

[WRoeckelein]

Hi Mr Graeff,

but an maintenance version should only receive bug and security fixes, so as long as the application does not rely on buggy behaviour, there should be no risk.

Also eg a UI problem because of a minor relase in a maintenance will get noticed by the users and can easily be dealed with, while a missed security update will get more or less unnoticed until is is exploited and then it is too late...

I think as tino.behrmann wrote, there should be definitly a developers/customers choice here be available, so more security sensitive customers will be able to make an appropriate decision.

As this is a cloud service, people expect (IMHO rightly) that the cloud service will deal with security updates (my customers already wondered why the HANA cloud service is not updated automatically when security issues come up and instead they have to manually trigger the update...), since one of the ideas of cloud service is to reduce administrative effort.

Regards,

Wolfgang

[WRoeckelein]

Hi serdar.simsekler,

see my answer in your other question.

Regards,

Wolfgang

[Oliver_S]

 

well, esp. in dev systems we have sometimes reverse requirements. the monthly cloud shipments  do not affect the on premise delivery. you get once a year one or 2 innovation SPs with SP00, maybe SP01, and the first maintenance SP also usually contains innovations. After that, all higher SPS and patch level are maintenance only.

The procedure restarts with the next higher SAP_UI version or Frontend Server version.