How to always use latest library version?

Help
#1

Hi,

I started looking into Libraries (reusable components) today and i’m having an issue with something. It might be that im not using library function the way its intended, if so let me know.

Lest say i have 2 Processes: ProcessA and ProcessB, they both use my LibraryA.

If i update LibraryA and publish it to Orchestrator, how can i make sure that ProcessA and ProcessB always runs with the latest version of the library?

I know i can open the projects in studio and manually update to the latest version, but this is really cumbersome and doesn’t scale very well if i need to update 50 processes which is a concern for me.

#2

Hi @nilschr

You are right it could be better and you should expect improvements in this regard in the incoming releases. For now it is indeed a manual process.

1 Like
#3

Yeah, I think you have the option in 18.4 to use “Strict” or “Lowest Applicable Version”. From my understanding, they were going to add another option for “Highest Applicable Version” or whatever.

Also, check this post here: #FeatureBlog - 18.3 - Library (Reusable components) - #16 by andreiT

Essentially, you could remove all old versions of the library from the feed, so the “Lowest Applicable Version” would be the newest version, therefore you would not need to update all processes.

2 Likes
#4

I knew there was one more workaround out there but couldn’t recall it and had to move on. Thanks! :slight_smile:

1 Like
#5

@ClaytonM @loginerror Do we have any updates on the feature of “Highest Applicable Version” for the libraries?

#6

It’s on the roadmap, that’s all I can say right now :zipper_mouth_face:

4 Likes
#7

Thats still great news, thanks for the follow up :slightly_smiling_face:

Quick Object Repository Demo
#8

Hello @mircea, @loginerror is there an update here on the Highest Applicable Version setting? This is sorely needed in our processes for a library to be scalable.

4 Likes
#9

Hi I am also interested in this topic any news regarding Highest applicable version?

3 Likes
#10

Hey! Any update on this release?

#11

second link shows what nuget is offering and what not

1 Like
#12

I’d like to add my voice to the voices here. It would be most helpful if all automations would use the most recent version of the published library automatically.

But this begs another question:

If I have version 1.01, 1.02, and 1.03 of a library published to my orchestrator and I have automations that use all three different versions of that library, is that what is in fact happening? The version of the library that’s being used is controlled by the version in the package?

To be more clear, Process A was published using version 1.02 of the library. Do I understand correctly that it will keep using version 1.02 of the library until I update packages from Studio and republish?

#13

@loginerror, is there any upgrade on this side? It would be highly appreicated :blush:

#14

This would be very bad. You don’t want it to be automatic, because changes in the later package version could break the automation.

To be more clear, Process A was published using version 1.02 of the library. Do I understand correctly that it will keep using version 1.02 of the library until I update packages from Studio and republish?

Yes

1 Like
#15

I answered yes to this, but there is one caveat. If you have conflicting dependency versions then the “strict” or “lowest applicable version” setting would come into play, and the automation might use a higher version of one of the dependencies.

I recommend reading this, specifically the Setting Dependency Rules and Resolving Dependency Conflicts sections.

#16

I wouldn’t say that it would be “bad”. If the implementation is robust enough it could have various version constraints and logical operators to signify what explicate, range, or minimum, maximum versions can be used. This can be used to constrain referenced packages to their minor or patch releases only for a major branch and that sort of thing.

While you cannot ensure that 3rd party projects/developers are conforming to a certain versioning scheme, this would put the flexibility and choice to each maintainer.

For those that are unaware UiPath also have the Project Dependencies Mass Update Tool

@Forum_Staff - It might be worthwhile to convert this topic into an idea if one doesn’t already exist.

#17

The Mass Update tool doesn’t avoid having to republish each automation, which for a company like us means going through change mgmt.

#18

Seems more of your specifics companies process in change management. We also do Change Management in this space, but building a package is done outside of that governance and the change/release management looks after the ‘enablement’ and configuration of the processes to be used in production.

Currently we publish packages to Orchestrator directly but will eventually publish to an external feed available to multiple environment/instances and after that move towards CI/CD pipeline.

#19

There are a LOT of companies who have these type of rules. Especially in regulated spaces like ours.