Docssdk 0.0.0Aether homeOpen Aether

Test and distribute a package

Validate the built package, exercise it in a real world, and choose the supported publishing path.

3 minute read

Test the same files you intend to publish. A passing source test does not prove that the built package contains the right files, requests the right permissions, or works after installation.

#1. Validate the package

For a hosted system, run:

TerminalShell
aether system validate .
aether system build .
aether system inspect dist/system.aethersystem.zip

Keep the inspection output with the release review. Building the same source twice must produce the same package identity.

For a mod, build the project and inspect the resulting bundle. The ZIP must contain mod.json at its root. Confirm that every requested permission appears in the mod capability reference, and remove permissions the mod does not use.

For a content or soundscape pack, validate the exported package rather than only the source project. Check every included file, reference, attribution, and rights declaration before uploading it.

#2. Exercise the real behavior

Install the built package in a disposable local or test world. Test with the least powerful role that should use each feature, then confirm that a user without the required role or permission is refused.

Cover the behavior that belongs to the package:

  • Systems: world creation, starter content, every document type and sheet, rolls, automation, companion applications, required packages, restart, and each declared upgrade path.
  • Mods: installation consent, panels and background behavior, requested permissions, reconnect, disable, update, and uninstall.
  • Content packs: import choices, id remapping, references, duplicate import behavior, and removal of content owned by the importing world.
  • Soundscape packs: included audio, cue and sequence playback, permissions, missing assets, and uninstall behavior.

Exercise one deliberate failure for every operation that changes a world. The previous working state must remain usable or produce a clear recovery instruction.

#3. Review what the user will see

Read the listing as a GM who has not seen the source project. It should name the actual contents, requested permissions, required packages, compatibility, limits, license, and creator-supplied rights declaration. Verify the cover and alt text at desktop and phone widths.

A Creator Studio draft saves the publication form but is not an installable test release. An Unlisted, link only item is already published and its version is immutable. Until private test releases are supported, use a local or dedicated test installation before publishing either a public or link-only version.

#Distribution paths

PackageDevelopment and testingPublication
Hosted systemBuild and inspect with the Aether CLI; install in a local or test worldUpload .aethersystem.zip through Creator Studio, or use the supported local/test CLI
ModInstall the built development manifest in a local or test worldUpload a ZIP with mod.json at its root through Creator Studio
Content packImport the exported .aetherpack.json in a disposable worldUpload .aetherpack.json through Creator Studio
Soundscape packImport the exported package and exercise its included audioUpload .aethersoundscape.json through Creator Studio

Published package versions cannot be replaced with different bytes. If any file changes after the review, update the package version and repeat the validation and real-world checks.

See Publish a system for the complete hosted-system publication flow and Build a mod interface for the mod development loop.

Was this page helpful?