How to always use latest library version?

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

1 Like

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

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

4 Likes

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

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

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

3 Likes

Hey! Any update on this release?

second link shows what nuget is offering and what not

1 Like

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?

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

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

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.

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.

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

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.

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

This would be very bad.

Would it though?

Imagine I’ve got 1000 automations all of whom log in to the same system to get started, and I’ve built a reusable component to handle the process of logging in (since it’s the same every time).

Now imagine that the login page changes and I have to adjust the login procedure.

Isn’t it far better to be able to change it in once place, publish, and be done with it rather than having to go to each of the 1000 automations and update them?

Notice the next few words after I said “this would be very bad.” I was specifically talking about it happening automatically. Yes, we need a tool where we can MANUALLY tell it to go update a bunch of Processes, but you wouldn’t want it to be AUTOMATIC.

I can definitely agree with that. Give us the option to push it out automatically or manually and that givse us complete control.

1 Like

This topic has been up a long time. Lets bring new attention to it.

Cast a vote :slight_smile: