How to handle custom Fiori Application version?

Intro

This title may sound a bit odd, but I want to tell you about a situation that happens to me quite frequently with my clients.

Imagine being asked to create a freestyle application or an extension of a standard. You do it and you deploy it all the way to production. The users are happy and ask you for an evolution, which you do and deploy on the quality system. Another evolution request arrives while the first one is being tested.

At this stage you have 3 versions of your application! Problem…. How to manage the correction of the bug that has just been reported on the production system?

To answer this question I will write two blogs. The first one (this one) which will explain the notion of versioning for a home-made Fiori application. And the second one which will explain how to manage these versions with Git Flow.

What is a Version?

I based my rebuild on the Semantic Versionning 2.0.0 reference. It explains that the version hierarchy must be built this way :

It is very important to have a clear and simple versioning system. At least, when you apply an HotFix the Patch number increase, if a new Feature is deployed then the Minor numbre is modified, and when the new version is no more compatible to the old one, the Major number is modified.

Where is that version number?

The answer is simple… in your manifest.json file at the applicationVersion attribute:

{	
"_version": "1.12.0",
  "sap.app": {
    "id": "ch.saphirnet.demo.odata.Demo_OData",
    "type": "application",
    "i18n": "i18n/i18n.properties",
    "applicationVersion": {
        "version": "1.0.0"
    },
    "title": "{{appTitle}}",
    "description": "{{appDescription}}",
    ...
}

In that example, the version is 1.0.0 and you can modify it easily.

Where to find it?

Now that we know how to have fun with version numbers, how can my users see it in order to communicate with me?

Thanks to the Launchpad, in the Me Area, you have the About option that gives you the information.

Conclusion

At this stage, you may not see the point of this notion of versioning, but I can assure you that the day you are going to implement this versioning system, the business will thank you, because you will be faster and more efficient in resolving bugs.

There’s one point I didn’t mention, but the fact of deploying applications with different versions, I noticed that the cache system was correctly managed.

The blog that is in preparation will exploit this version notion and integrate it in a Git Flow.

References

Image: https://onlinestore.id/2018/07/03/semantic-versioning-onlinestore-id/