Add-on Publishing Guide
This guide explains how to publish and maintain add-ons on the Return of Reckoning Addons site. It summarizes the current site workflow; use the linked format and API documentation for full technical details.
Find and inspect add-ons
The catalog can be searched and browsed by category or career, and sorted by recent updates, downloads, rating, or name. An add-on page provides its latest download, game-version information, release history, modules and dependencies, changelog, screenshots, comments, and developer information. Check the release channel and date before choosing a version.
Prepare a package
Read the add-on format specification before uploading. The package is a ZIP that extracts directly into `Interface/AddOns`, with one folder per module and a `.mod` file in each module folder. Bundles may contain several modules.
The registry reads the module name, dependencies, game version, categories, careers, and replacement declarations from each `.mod` file. It sets the module version to the release version. Use strict Semantic Versioning. Packages must be 25 MB or smaller when compressed and must not contain executables, scripts, or nested archives. The registry removes common junk files such as `Thumbs.db` and `.orig` files.
Submit a new add-on
Sign in to the site and choose **Submit an addon**. Provide a name and permanent URL slug, a short summary and Markdown description, choose whether the package is an add-on or library, and select its visibility. You can add a forum thread and source repository, choose an initial version, upload the ZIP, write a Markdown changelog, and select categories and careers. Categories declared in package metadata can be added automatically.
The submitted archive is inspected and normalized. The first release goes through moderator review before it is published. Public add-ons appear in browsing and search; unlisted add-ons are reached by link; private add-ons are limited to their permitted audience. Review the visibility choice before submitting.
Publish later releases
From **My addons**, open the add-on and start a new release. Enter a Semantic Version, upload the package ZIP, and provide release notes. The site checks and rebuilds the archive, applies the release version to module metadata, and resolves dependencies. A release may be published automatically for trusted maintainers; otherwise it waits for moderator approval. The release page shows its channel and status.
Manage an add-on
The add-on’s **Developers** area shows its listed developers and whether it has been claimed. If you need to establish ownership of an existing project, use the site’s claim or support process shown there; do not assume that being the original author automatically grants account access. Maintainers can edit add-on details and manage access. Contributors can upload releases. A moderator grants trusted-maintainer status per add-on.
The edit area manages description, links, tags, icon, screenshots, members, source integration, and visibility. The site accepts a square icon and resizes it to 256-pixel WebP. Add concise captions to uploaded screenshots. Treat a visibility change to or from private carefully because it moves package files between storage areas.
Publish from a GitHub repository
A maintainer can connect a GitHub repository in the add-on’s **Edit → Source** settings. For a public repository, enter its URL and keep the default tag pattern if you use version tags such as `v1.2.3`. A repository subdirectory can be specified when the add-on files are not at the repository root. Private repositories require a repository access token; use the site’s source settings guidance and grant only the access needed.
The repository should contain the add-on’s normal module folder and package files. In the module metadata, use `@project-version@` and `@project-date@` placeholders where appropriate so the site can fill them from the release tag. Check the site’s current API and repository integration documentation for supported archive layout and tag rules before connecting a project.
After linking the repository, use **Sync tags now** to check existing tags. The site also polls for tags periodically; an optional GitHub webhook can notify it sooner. Webhook setup is shown in the Source settings. Keep the webhook secret private and never include it in screenshots, commits, or public documentation.
When a maintainer pushes a new matching version tag, the site fetches that tagged source and prepares a release. Review its import status in the add-on’s Source settings and follow any site review or approval step shown there. Do not reuse a tag for a release already published on the site; create a new tag for a new version.
Accept contributions with GitHub pull requests
The add-on site does not provide an in-browser code review or merge request workflow. Contributors can fork the GitHub repository, make a change on their fork, and open a pull request against the add-on’s repository. The maintainer reviews and merges the pull request on GitHub. After merging a ready change, the maintainer publishes a new version tag; the connected add-on site can then import that release. Include clear setup notes and contribution guidance in the repository README.
Automate releases
For CI publishing, use the API documentation. The API supports read-only catalog and release data and authenticated release uploads. Create a scoped personal token in account settings only when needed, store it in your CI secret store, and send it as a Bearer token; never commit it to the repository or include it in logs. Release uploads return a status URL that CI can poll. The API documentation includes GitHub and GitLab examples and explains repository tag integration.
Collections and UI profiles
Collections group add-ons into a shareable pack. A collection revision can pin an add-on to a specific version or follow a release channel. Public collections are listed; unlisted collections are link-only; private collections are restricted to members. Review the collection draft and its revision before publishing.
Collections can also include UI profiles. See the UI profile format for archive layout and allowed settings. A published profile becomes part of a collection revision; players can install selected profiles through the launcher.