Searchy uses SemVer-style versions with pre-release tags while the bot is still
before v1.0.0.
Searchy uses two long-lived branches:
devβ development. Day-to-day work lands here, and the## Unreleasedsection ofCHANGELOG.mdtracks what has merged but is not yet published.mainβ publication. Every released version β pre-release (alpha/beta/rc) and stable β is merged fromdevintomainand tagged there.mainalways reflects the latest published release.
Releasing renames ## Unreleased to the new version, merges dev β main, and
tags the version on main. See releases.md.
The first release line moves through these tags:
v0.1.0-alpha.1 initial open-source MVP code
v0.1.0-alpha.N further alpha hardening
v0.1.0-beta.1 first real Telegram/SearXNG beta
v0.1.0-beta.2 personal Vido DM handoff from shared group cards
v0.1.0-beta.3 About-panel version display fix
v0.1.0-rc.1 joint Searchy Γ Vido candidate after the full delivery smoke
v0.1.0 public MVP release
v0.2.0-alpha.1 relevance, discovery pools and per-user search locale
v0.2.0-alpha.2 dead-result and video cover-card hardening
After the public MVP release:
v0.1.1 bug fixes without new behavior
v0.2.0 stabilized relevance and discovery improvements
v1.0.0 stable production contract after real production usage
- Use
alphawhile core flows are not proven with real Telegram credentials and a live SearXNG instance. - Use
betaafter the bot works end to end, but only for limited users. - Use
rcwhen the release is intended to become public and only fixes are expected. - Use patch versions for fixes that do not change product behavior or runtime assumptions.
- Use minor versions for visible UX improvements, operational improvements, or search/delivery changes that remain in MVP scope.
- Do not use
v1.0.0until the bot has real production history, stable deployment practices, and a clear behavior contract.
Before v1.0.0, Searchy can still change faster than a mature product, but
breaking changes must be explicit when they affect:
- required environment variables
- PostgreSQL analytics schema or migration requirements
- SearXNG query, engine, or JSON-API assumptions
- shared
corebehavior (functions, role,search_path) and saved-language resolution - Docker Compose or deployment assumptions