Extension major-release regression

Your extension has to prove against every Acumatica major release, and the treadmill never slows down.

You get. Scenario suites per extension, executed against each release candidate as a gate in the build pipeline you already run — the same regression engine as tenant major-release regression, packaged for an ISV release cadence.

Pass/fail is not a substitute for your own release sign-off — liability language stays explicit.

I wire release-certification scenarios with the same regression engine that runs Acumatica major-release regression for VARs.

“Why not just wait for customer tickets after each Acumatica major release?”

Field feedback finds real usage paths automation never covers. After a quiet release with a thin install base, reactive support can be cheaper than a formal suite.

• →Customers find breakage first. Tickets arrive after publish — angry partners, support load, and a reputation hit on the marketplace page. The cost is not zero; it is deferred and less controllable.
• →No step-level evidence before release candidate. Without scenarios in the pipeline you already run, failure shows up as a vague “it broke on 2025 R2,” not a named step on a named candidate.
• →The treadmill does not slow down. Two Acumatica major releases a year means two chances to republish customizations blind. Waiting for tickets does not shrink that cadence.

Use field tickets for surprises automation will never see. Use extension major-release regression when each release candidate needs pass/fail in the pipeline before customers do the finding.

Plug scenarios into your pipeline → run against non-prod Acumatica with the extension → pass/fail per release candidate.

Nothing installs inside Acumatica as a product license. Same regression engine as tenant major-release regression — subject is the extension, not the tenant; cadence is the ISV release treadmill.

→Scenarios plug into the pipeline you already run

Scenario suites attach to your CI runner or an agreed invoker — not a parallel toolchain you operate alone. First pilot is one extension × one upcoming Acumatica major release.

→Run against non-prod Acumatica with the extension installed

Non-prod Acumatica with the extension loaded and sample tenant data that exercises the extension. Failures name the release candidate and the step — not a customer on the phone after publish.

→Pass/fail report with failure evidence

One extension × one Acumatica major release first, then every-release expand after the format is trusted. Pass/fail is not a substitute for your own release sign-off — liability language stays explicit.