Skip to content
This repository was archived by the owner on Aug 18, 2026. It is now read-only.

chore: deprecate in favor of the built-in substreams sink commands - #133

Merged
GabrielCartier merged 2 commits into
developfrom
chore/deprecate-in-favor-of-substreams-cli
Aug 18, 2026
Merged

GabrielCartier merged 2 commits into
developfrom
chore/deprecate-in-favor-of-substreams-cli

Conversation

@GabrielCartier

@GabrielCartier GabrielCartier commented Jul 29, 2026 •

Copy link
Copy Markdown
Contributor

What

Marks this repo deprecated. The SQL sink was folded into the main substreams CLI in streamingfast/substreams#830 and shipped in v1.20.2 as substreams sink postgres / substreams sink clickhouse.

  • README: deprecation banner at the top with the old→new command mapping and a link to the upstream migration guide. Existing docs kept below for people still running the binary.
  • CHANGELOG: Unreleased → Deprecated entry.

Why lead with database compatibility

The first question an operator asks is whether they have to rebuild. They don't — cursor tables and schemas are unchanged, so the CLI resumes from the stored cursor against the same DSN. The banner says that before the command table.

Deprecation terms

Per @maoueh: maintenance mode lasts one year with security fixes only (if any), no new features. The repo is then archived read-only so existing releases, tags and Docker images keep working. No hard EOL date. Merging does not wait on the #830 release announcement.

Archiving the repo, the Docker image / brew formula notices and a pinned issue are follow-ups, not part of this PR.

The SQL sink was folded into the substreams CLI
(streamingfast/substreams#830) and ships in v1.20.2 as
`substreams sink postgres` / `substreams sink clickhouse`.

Add a deprecation banner with the command mapping and a pointer to the
upstream migration guide, plus a CHANGELOG entry. Databases are
compatible in place, so the note leads with that.
@GabrielCartier
GabrielCartier requested a review from maoueh August 14, 2026 09:08
@GabrielCartier

Copy link
Copy Markdown
Contributor Author

@maoueh adding you, whenever were ready to deprecate this.

@maoueh

maoueh commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

Is "maintenance mode, will stop receiving releases" the wording we want, or do we want a hard EOL date?

Maintaince mode let's for a year with only security patches, if any.

Do we also want to archive the repo

Read-only so every existing continue working.

Draft until the #830 release is announced publicly.

Can be done without waiting for an announcement

@GabrielCartier
GabrielCartier marked this pull request as ready for review August 18, 2026 14:10
@GabrielCartier
GabrielCartier removed the request for review from maoueh August 18, 2026 14:10
Maintenance mode lasts one year with security fixes only, then the
repo is archived read-only. Previous wording claimed releases stop
entirely, which is wrong.
@GabrielCartier

Copy link
Copy Markdown
Contributor Author

Thanks — folded all three into e73178e:

  • Banner and CHANGELOG now say maintenance mode for one year, security fixes only (if any), no new features. Dropped the "will stop receiving releases" line, it was wrong.
  • Added that the repo is then archived read-only, with existing releases/tags/Docker images staying available so anything already running keeps working.
  • Undrafted, not waiting on the announcement.

Actually archiving the repo, the Docker/brew notices and a pinned issue are left as follow-ups.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants