# Migration numbering

Upstream (`iamxvbaba/gramsrv`) numbers its migrations sequentially
(`0001`, `0002`, ..., currently up to `0092`). This fork periodically merges
upstream, and upstream keeps adding its own sequentially-numbered migrations
between syncs.

**Any new OwpenGram-specific migration must use a `YYYYMMDDHHMMSS` timestamp
as its version instead of continuing the sequential numbering** — e.g.
`20260713103024_owpengram_system_account_brand.up.sql`.

Why: golang-migrate treats the version as a plain number and only cares
about ordering, not format. If we keep picking "the next free sequential
number" for our own migrations, the next upstream sync is very likely to
have independently picked the *same* number for one of its own new
migrations — two different new files, so git sees no conflict, and the
collision only surfaces at server startup (`iofs source: failed to init
driver ... duplicate migration file`, see `deploy/deploy_test.go`'s
`TestMigrationsLoad` for the regression test that now catches this at
`go test` time instead). This happened once already (our `0086`-`0088`
collided with upstream's own new `0086`-`0088`), and renumbering our
migrations to fit after upstream's (`0093`-`0095`) would only have deferred
the exact same problem to the *next* sync.

A 14-digit timestamp is always numerically larger than upstream's 4-5 digit
sequential numbers, so it always sorts after everything upstream has today
or will plausibly reach, and it never collides with another OwpenGram
migration as long as two aren't created in the same second. No renumbering
is ever needed again on future syncs — just keep using the timestamp at the
time the migration is written.

Upstream's own migrations keep their original sequential numbers untouched;
only migrations authored in this fork use the timestamp scheme.

## Removed feature: Stars, Star Gifts, Account Rating

The Stars economy, Star Gifts (collectibles/NFT gifts, local TON ledger),
and the Account Rating system were fully removed from the server (all
application/domain/store code and admin panel UI deleted). Their migrations
stay in place unmodified and are not reverted — this repo's convention is to
never renumber or delete migration history. The corresponding tables are
inert/orphaned as of the removal; this is intentional, not an oversight.