Cucumber 7.0 namespace shift: legacy cucumber.api package retention undecided

Direct answer

Do not plan around continued publication of the legacy cucumber.api artifacts. The move to io.cucumber is a breaking namespace change, and the old coordinates should be treated as deprecated. Until the maintainers publish a concrete retention policy, the safe assumption is that future Cucumber-JVM releases will drop the legacy modules rather than dual-publish them.

Confirmed facts vs. likely explanation

Status	Statement
Confirmed	Cucumber 7.0 moved the public API to io.cucumber and deprecated the cucumber.api package.
Confirmed	No official compatibility shim or dual-publish strategy has been announced for the legacy namespace.
Likely	The legacy artifacts will be removed after the deprecation window, not retained indefinitely.
Uncertain	The exact version that removes cucumber.api varies by module and release train; verify per artifact.

Recommended path when immediate migration is blocked

1. Pin to the last version that still ships the legacy namespace. Freeze your Cucumber-JVM dependency until every blocker is resolved.
2. Isolate test code behind stable abstractions. Route annotations, hooks, and type references through custom base classes or a thin internal wrapper so the bulk of your suite does not import cucumber.api directly.
3. Use IDE-level import rewriting incrementally. Bulk refactoring tools can update Java imports, but they often miss string-based references in plugin configuration, custom formatters, or reflection-based runners. Audit those manually.
4. Handle lagging third-party reporters by pinning or replacing. If a plugin has not released an io.cucumber-compatible build, keep the Cucumber version pinned until it does, or swap the plugin. There is no official bridge for old plugin APIs.
5. Time-box any temporary internal adapter. Wrapping new io.cucumber APIs behind legacy interfaces can unblock a phased migration, but it adds maintenance cost and should be removed once the cutover completes.

Verification steps

Because the removal cutoff is module-specific, confirm the state of each artifact you use rather than assuming a single global version.

• Check the Maven Central or Gradle Plugin Portal listing for your exact Cucumber-JVM modules (for example, cucumber-java, cucumber-junit-platform-engine) to see whether legacy coordinates are still published.
• Inspect the dependency tree for transitive pulls of the old groupId and exclude them explicitly if present.

# Gradle: look for legacy groupId in the test runtime classpath
./gradlew dependencies --configuration testRuntimeClasspath | grep -i cucumber

# Maven: filter the tree for Cucumber artifacts
mvn dependency:tree -Dincludes=info.cucumber:*

• Run a minimal smoke test with one feature file after switching to io.cucumber to confirm that the engine, plugins, and reporters load without NoClassDefFoundError.
• Never mix old and new artifacts on the classpath; duplicate annotations and SPI loaders can cause silent test-discovery failures.

Missing diagnostic detail

Which specific Cucumber-JVM modules and versions does your project currently declare? The exact legacy cutoff differs by module, so the module list changes whether pinning is a short-term fix or a long-term risk.