Impact of upgrading Designer from 8.1.27 to 8.1.30

for some reason everyone here is stunlocked when i mentioned upgrading to the 8.1.30 to fix some of the display issues we're having. i'm presuming a simple dot.dot update should have virtually no impact on the Ignition Gateway dynamics or any downstream impact that would cause such a reaction. is there something i don't know about?? PTSD from a 7 to 8 migration?

Where's "here"? At your company?

Point releases are generally safe, but I'm not sure what logic leads you to assume they couldn't affect the Gateway as well.

The Gateway and Designer are all packaged together as one software release. You can't upgrade any piece on its own.

The Move fast and break things mantra was alien to corporate IT and dangerous to an IT manager's career in a business that wasn't about inventing IT.
It is dangerous to more than that for OT and control systems.

That presumes you aren't in a regulated environment - something like GMP might introduce additional requirements for any change.

The official strategy in many places was to Make it work, make it stable, and then leave it alone. The slammer virus changed that for places that were hit, but change control and upgrades are still a big deal. CI/CD may be presumed for many environments but the infrastructure, practices, and mindset are not there for OT.

Security patches and tech refresh to remedy EOL are usually easier to sell than cosmetic or ease of use.

i see. i thought they were a package of collected tools. when i launch the About Ignition Designer menu item, it pops up a window with several modules, all running differing version numbers. this led me to believe Designer was just part of an ecosystem, not a piece of the entire thing.

question still stands, though, what's the impact?

Yeah, there's a bit of a modular architecture going on, but the Gateway and Designer are pretty tightly coupled.

The "impact" is everything you see in the change logs for the intermediate versions plus some amount of regression risk.

1 Like

See where a recent upgrade broke stuff. It was low criticality and was fixed quickly but is a reminder that something could go wrong and provide wrong data to the end-user.

exactly. i'll hunt around for a bug list for the .30. it sounds like there are more 'gotchas' than i thought, since nobody has yet to say 'go for it!' or 'impact is minimal, see this...'.

Too soon. A week after release is my threshold for development purposes. At least a couple weeks for production purposes. (Which is way faster than I adopt almost any other major piece of software.)

2 Likes

And even then, I'll only upgrade after some good testing on a development environment (which is where I ran into the menu issue).

2 Likes

goes without saying. i've been on the 'please com fix this' end of things way too often. :smiley:

There have been a couple of exceptions when we wanted newly released features, but our standard practice is to do quarterly updates to a "current release - 1" level on our production system. Overall there haven't been too many problems, but we always do system retests between the updates and the next production shift. "Low Risk" is very different than "No Risk".

1 Like

good practice. sometimes a few months will highlight something is a weird use-case scenario you'd have never thought of until the day after a wild nigh of karaoke, ginger beer, and pop tarts. :smiley:

1 Like