Choosing an Upgrade Strategy

Why upgrade

Every Posit Workbench, Posit Connect, and Posit Package Manager release falls out of support 18 months after it ships. Upgrading regularly keeps you eligible for help from Posit support. It also means that your configuration, extensions, and integrations stay close to what the current release expects. Each jump stays small, moving from one recent release to the next changes far less than crossing several releases at once.

Four upgrade postures

Every organization lands somewhere on this spectrum, whether they choose it deliberately or not. Choose one on purpose so you can develop a plan and communicate it with the rest of your team.

1. Latest and greatest

Upgrade to the newest release as soon as it is available. You get the newest features first, and you help shape where the product goes next.

If you run this posture, give feedback on new features, and report issues you hit. Early adopters have an outsized effect on product direction.

2. Cautious

Stay one or two releases behind the latest. You upgrade once a release has had time to settle.

3. Within support window

Upgrade only when you are near the edge of the 18-month support window. This posture accumulates a large set of breaking changes between upgrades, so each jump requires careful testing before going to production.

Recommendation

Upgrade at least every 18 months. Quarterly or monthly is better.

A regular cadence keeps you inside the support window. It gets you features, performance, and security fixes soon after they ship. It also reduces risk of any single upgrade, since each jump covers less ground.

Which posture fits you?

Use these questions to place yourself on the spectrum. None has a single right answer, but together they point toward a posture that matches your environment and constraints. Whatever they suggest, keep upgrading. The questions shape how and how often you upgrade.

How easily can you test an upgrade before it reaches production?

A staging environment that mirrors production (same node count, matching database, mirrored storage, same operating system) lets you catch breaking changes before users see them. If you can keep a staging server current, it is easier to run close to the latest release. If you don’t, stay a release or two behind.

How reversible is an upgrade in your setup?

Rollback options are narrow. The harder recovery is for you, the more you should test first, not the less often you should upgrade. Always back up before you start.

How many integrations could an upgrade disturb?

Count what connects to the product: external authentication (SAML, OIDC, LDAP), the database and its version, the R and Python versions your content is pinned to, and any downstream systems. Each one widens what you must re-test on every upgrade. Heavy coupling argues for a cautious posture and a documented checklist, not for skipping releases. Running several R and Python versions side by side, rather than replacing one, keeps existing content working across upgrades.

Do you operate under change control or regulatory constraints?

Approval workflows, validated environments, and fixed maintenance windows add lead time to every change. If that describes you, plan your cadence around your change windows rather than the monthly release calendar, and favor a steady, predictable schedule over reacting to each release. This usually lands you in the cautious or within-support posture, run on a plan.

What can your team’s capacity sustain?

Regular, small upgrades cost less per event than rare, large ones, because each jump covers fewer breaking changes. If time is tight, that’s an argument for a steady cadence, not against upgrading: a monthly or quarterly rhythm spreads the work and keeps each step small. Skipping upgrades for years concentrates all the risk and effort into one high-stakes project.

How much do you value early access and influence?

If getting new features first matters, or you want your feedback to shape where the product goes, the latest-and-greatest posture rewards that. The issues you report and the feedback you give feed directly back into upcoming releases.

Add up where your answers point. Strong testing, light coupling, and appetite for features pull toward latest and greatest or cautious. Heavy coupling, tight change control, or limited capacity pull toward the cautious or within-support end. Wherever you land, write the posture down, set a cadence, make a plan, and revisit both as your environment changes.

Release cadence

All Posit professional products (Workbench, Connect, and Package Manager) use calendar versioning: YYYY.MM.patch. New releases ship monthly.

Important

Rollback options are limited and differ by product. That is why choosing a posture and testing on staging matter. See Upgrading safely.