mirror of https://github.com/apache/superset.git synced 2026-05-23 08:45:45 +00:00

Files

Claude Code 4ee42fe5b8 docs: cut 6.1.0 versions for user_docs, admin_docs, developer_docs, components

Snapshots all four versioned Docusaurus sections at v6.1.0, cut from
master after the version-cutting tooling (#39837), broken-internal-
links fix (#40102), and user_docs rename (#40171) all landed. With
the rename in place, all four sections now produce parallel-named
files at the docs/ root (no more bare `versioned_docs/` outlier).

Versioning behavior: lastVersion stays at current for every section,
so the canonical URLs (/user-docs/..., /admin-docs/...,
/developer-docs/..., /components/...) continue to render content
from master. The current version is consistently labeled "Next"
with an unreleased banner, and 6.1.0 is a historical pin accessible
only via its explicit version segment.

Component playground: previously disabled: true in versions-config.json,
now enabled and versioned.

Snapshot includes:
- All MDX content for the four sections.
- Auto-gen captured fresh: 74 database pages (engine spec metadata),
  ~1,800 API reference files (openapi.json), 59 component pages
  (Storybook stories).
- Data imports frozen at cut time into snapshot-local _versioned_data/
  dirs:
    user_docs_versioned_docs/version-6.1.0/_versioned_data/src/data/databases.json
      (canonical 80-database diagnostics from master, preserved by the
      generator's input-hash cache)
    admin_docs_versioned_docs/version-6.1.0/_versioned_data/data/countries.json
    admin_docs_versioned_docs/version-6.1.0/_versioned_data/static/feature-flags.json
    developer_docs_versioned_docs/version-6.1.0/_versioned_data/static/data/components.json
- Import paths in deeply-nested files rewritten so they still resolve
  from one directory deeper inside the snapshot.
- developer_docs/extensions/overview.md snapshot has the FIXED
  ./mcp.md form (from #40102), so the SPA-nav 404 isn't baked into
  the 6.1.0 version.

Verified via full yarn build: exit 0, no broken links surfaced by
onBrokenLinks: throw.

2026-05-15 22:36:30 -07:00

2.1 KiB

Raw Blame History

title, sidebar_position

title	sidebar_position
Deployment	7

Deployment

Once an extension has been developed, the deployment process involves packaging and uploading it to the host application.

Packaging is handled by the superset-extensions bundle command, which:

Builds frontend assets using Webpack (with Module Federation configuration).
Collects backend Python source files and all necessary resources.
Generates a manifest.json with build-time metadata, including the contents of extension.json and references to built assets.
Packages everything into a .supx file (a zip archive with a specific structure required by Superset).

To deploy an extension, place the .supx file in the extensions directory configured via EXTENSIONS_PATH in your superset_config.py:

EXTENSIONS_PATH = "/path/to/extensions"

During application startup, Superset automatically discovers and loads all .supx files from this directory:

Scans the configured directory for .supx files.
Validates each file is a properly formatted zip archive.
Extracts and validates the extension manifest and metadata.
Loads the extension, making it available for use.

This file-based approach simplifies deployment in containerized environments and enables version control of extensions alongside infrastructure configuration.

2.1 KiB Raw Blame History

Deployment

2.1 KiB

Raw Blame History