Skip to content
Start here

Alpha status & versioning

What "early alpha" means for RedScribe, current known limitations, and how versioning and releases work.

RedScribe is early alpha (0.7.0-alpha as of this writing). Expect rough edges and breaking changes between releases, and read this page before relying on it for a real client engagement.

  • No public API. Every workflow is web-UI-driven. There’s no REST/GraphQL API to automate against yet.
  • The first-run /setup/ page is a race, not an invite-only step. It creates the instance’s first Superadmin account and has no login of its own to gate it, by design, there’s no admin yet to log in as. It works exactly once: the moment any Superadmin exists, it refuses to do anything further. In the window between an instance coming up and someone completing that form, whoever reaches it first becomes the Superadmin — normally the operator, moments after docker compose up, but on a network reachable by anyone else before that happens, it could be someone else instead. No engagement data exists yet at that point (nothing to disclose), and the CLI-only bootstrap_superadmin command is the alternative if you’d rather not expose the web form at all on a network you don’t fully trust yet. See First run for both options.

RedScribe follows Semantic Versioning: MAJOR.MINOR.PATCH, with a -alpha / -beta / -rc pre-release suffix before the first 1.0.0. The current version lives in the repo’s VERSION file (a single line, no v prefix) and is tagged in git as v<version> (for example v0.1.0-alpha).

Pre-1.0, expect breaking changes on minor bumps (0.1.0 to 0.2.0). That’s normal during alpha, not a mistake. Once RedScribe reaches 1.0.0, standard SemVer rules apply: PATCH for fixes, MINOR for backward-compatible additions, MAJOR for breaking changes.

CHANGELOG.md, in the repo root, follows Keep a Changelog format. Every release gets a dated entry there before being tagged. See the Changelog page for the current history.

# 1. Update VERSION and move [Unreleased] CHANGELOG entries into a new dated section.
# 2. Commit, then tag:
git tag -a v0.7.0-alpha -m "v0.7.0-alpha"
git push origin v0.7.0-alpha