Abhiram Diddigi home

Semantic Versioning in Service Now

Naming the update sets is a very tricky and confusing process. Say you developed a functionality today, and then added that to an update set, then after a month fixed some enhancements , and then bug fixes.We need to follow some very robust mechanism so that we can trace our Updates back. The reminder of the section will concentrate on how well you can do this to avoid any confusion, using Semantic Versioning

The current versioning format that I follow usually is:

[code] the-name-of-the-client/module/submodule/anyrandomstring

the-name-of the client - Is the name of the client that I work for, Not the name of the company i work with. submodule - Is anything like CM/IM/SC/PM anyrandomstring - Any random string which will tell what I’m doing - human readable form.

[/code]

and let me tell you this is a strict no-no(read on).

Now, the above way of versioning is way too confusing, You really don’t have a way to identify what enhancement is going on, from the name, and is there any changes to that enhancement and/or is that a bug fix to that enhancement.

Semantic Versioning (if you have opened the above link) states that :

Though in Service Now we really don’t have a API that we are working with, hence modifying the semantic versioning and extending it to Service Now.

The Update set should follow the following naming conventions: