Package versioning semantics

Help Orchestrator
,
1

Hi all,

What are your best practices for package versioning semantics? I found here the “proper” way to do it for all NuGet packages.

The article specifies as follows:

  • Major: Breaking changes
  • Minor: New features, but backwards compatible
  • Patch: Backwards compatible bug fixes only

What exactly is your interpretation of this in terms of RPA? Many times, an application or website will slightly change where a single selector will no longer work. This is a very small and simple fix, yet it would be considered a “breaking” change because it would be impossible to roll back to a previous version of the automation.

Do you guys just have very large major version numbers, updating them any time an application changes in a slight way that makes it no longer backwards compatible?

Or do you still consider a change like that a bug fix? A minor change?

All the best, Andres.

2

Hi @aquesada ,
When creating robots, we can prevent all possible changes of the website.
eg show ads,…
Adjusting its Properties also helps them to limit errors as much as possible
However, the change is too big from the website, it is natural for the robot to have to repair
RPA mimics human actions
can’t do a job that hasn’t been assigned in advance
Regards,
LNV

3

Hi @Nguyen_Van_Luong1

I was asking specifically how you handle these things as far as what to number your package releases when publishing the package to orchestrator.

For example, package version 1.0.0 is the first release of a process. If you had to just update a single selector that has changed on a website, would you call it 2.0.0 or 1.0.1 ?

The first number is supposed to be updated on “major” changes that prevent rollback. The middle number on “minor” changes that add new features that are backwards compatible, and the last number is supposed to be a “patch” that fixes bugs. These are the rules for packages generally. But I wonder how others are adhering to this in the world of RPA or if anyone has any good interpretations they enforce in their COE.

Andres

4

Hi @aquesada

A bit late, but hopefully others might find this informative.

At out business we are currently working on moving away from SemVer (Major.Minor.Patch.Revision) and will move to CalVer (Year.Month.Date.Revision).

We do that for multiple reasons

  1. UiPath uses CalVer (Year.Month.Reivsion) - we will also append the “-preview” postfix for changes on the non-main branches.
  2. Wee see that out developers dont actually updates Major or Minor versions anyway.
  3. CalVer just gives a better overview of when changes have actually been made.

All our projects are going through a CI/CD pipeline in Azure DevOps.

1 Like