Release Readiness

Guidelines for indicating that a resource is stable and ready for release.

Code Quality

1. No lint errors are present.
2. All print statements are replaced with lib.print.
3. ox_lib is used to replace natives where possible.
4. Code uses best practices and follows the contribution guidelines.
5. Code is readable and well organized.
6. No deprecated functions are being invoked.

Database Practices

1. Does not read directly from tables it does not own, and uses exports and functions from the owning resources to get the data instead.
2. Has direct database calls to tables it does own in a designated storage layer of the resource (see server/storage.lua in qbx_core).

Config Practices

1. Config is located inside of a config folder and is split between client.lua, shared.lua, server.lua, and optionally more. Each of these are a module (i.e. returns a table).

Core Practices

1. Client PlayerData is accessed using playerdata module, instead of a qbx_core export.
2. Lib module is used to replace duplicate code like DrawText.

Resource Quality

1. Resource features provide a good experience for players/devs/owners/admins.
2. Resource is scoped appropriately (i.e. it shouldn't be split, or combined with another resource).
3. README is not outdated.
4. No known bugs.

Stability

1. No breaking changes are planned in the near future.
2. Resource has been tested or unchanged for long enough to give confidence that major bugs are not present.

Dependencies

1. Dependencies are declared and enforced using lib.checkDependency (opens in a new tab). fxmanifest dependencies should be used intentionally; understanding the behavior of restarting a resource.
2. Dependencies are stable.

Release Automation & Documentation

1. The first line of code executed by the server is lib.versionCheck (opens in a new tab).
2. The resource has a .github folder with bug/suggestion templates, automated version updater & release script.
3. The resource has a README which contains marketing material about the resource and it's features. Note that this is not technical documentation.
4. The resource's public API (events & exports) are documented on the technical docs (here).