Skip to content
Rime Docs

Pipeline Versioning

Every edit to a pipeline creates a new version. Rime maintains a complete history of all pipeline versions, making it straightforward to review what changed, when, and by whom — and to revert to a previous configuration if something goes wrong.

How versioning works

When you create a pipeline, it starts at version 1. Each time you save changes to the pipeline’s structure (adding, removing, or modifying steps, or changing connections between them), Rime creates a new version with an incremented number.

The current version is the one that executes when the pipeline runs, whether triggered manually or by a schedule. Previous versions are retained for history and rollback but do not execute.

Changes that create a new version:

  • Adding or removing a step
  • Changing a step’s configuration (e.g., selecting a different connector, modifying SQL, changing timeout)
  • Adding or removing a dependency edge between steps
  • Changing a step’s failure policy
  • Reordering steps on the canvas does not create a new version (layout is cosmetic)

Changes that do not create a new version:

  • Modifying the pipeline’s schedule (schedule changes are tracked separately)
  • Renaming the pipeline
  • Changing the pipeline description

The is_current flag

Each version has an is_current flag. Exactly one version is current at any time. This is the version that:

  • Appears when you open the pipeline in the DAG builder
  • Executes on scheduled or manual runs
  • Is returned by the API when querying pipeline details

When you save a new version, the previous version’s is_current flag is set to false and the new version’s flag is set to true.

Viewing version history

To see all versions of a pipeline:

  1. Open the pipeline page
  2. Click the Versions tab
  3. The version list shows:
ColumnDescription
VersionSequential version number
CreatedTimestamp of when this version was saved
Created byThe user who made the change
StatusCurrent or Previous
SummaryA brief auto-generated description of what changed (e.g., “Added Transform step”, “Removed webhook”, “Changed SQL in step 3”)

Click any version to view it in a read-only DAG view. The current version is always at the top of the list.

Comparing versions

To compare two versions side by side:

  1. In the version list, select two versions using the checkboxes
  2. Click Compare
  3. Rime displays both versions side by side with differences highlighted:
    • Green — steps or edges added in the newer version
    • Red — steps or edges removed in the newer version
    • Yellow — steps whose configuration changed

The comparison also shows a text diff of step configurations, so you can see exactly what settings changed (e.g., which connector was swapped, what SQL was modified).

Rollback

If a pipeline change introduces problems, you can revert to a previous version:

  1. Go to the Versions tab
  2. Find the version you want to restore
  3. Click Rollback to this version
  4. Confirm the action

Rollback does not delete the current version or overwrite history. Instead, it creates a new version that is a copy of the selected previous version. The version sequence continues incrementing:

Version 1 (original)
Version 2 (added webhook step)
Version 3 (changed SQL -- introduced a bug)
Version 4 (rollback to version 2 -- copy of version 2's steps and configuration)

Version 4 is now current. Versions 1 through 3 remain in the history. This approach ensures the version history is a complete, append-only record — you can always trace what happened.

What rollback copies

When you rollback to a previous version, the following are copied to the new version:

  • All steps and their configurations
  • All dependency edges
  • Step-level failure policies

The following are not copied:

  • The pipeline’s current schedule (schedule is not versioned)
  • Run history (execution logs belong to the version that was active when the run occurred)

Rollback and running pipelines

If a pipeline is currently executing when you rollback, the in-progress run continues using the version it started with. The next run (manual or scheduled) uses the new current version.

Version metadata

Each version records:

  • Who — the user ID and display name of the person who saved the version
  • When — the UTC timestamp of the save
  • What — an auto-generated summary of changes, plus the full step and edge configuration as structured data

This metadata is available in the UI and through the API. It supports audit requirements — you can answer “who changed this pipeline and when?” without digging through external version control.

Interaction with pipeline execution

Execution runs are linked to the version that was current when they started. This means:

  • If you view a past run’s details, the step configuration shown matches the version that was active at the time, not the current version
  • Comparing a failed run’s version against the current version can help identify whether a recent change caused the failure
  • Run logs are permanent even if the associated version is no longer current

See Pipeline Execution for details on monitoring and inspecting runs.

Best practices

  • Review before saving. Once saved, a version cannot be edited — only superseded by a new version. Use the preview pane to verify step configurations before clicking Save.
  • Use descriptive step names. Good step names make auto-generated version summaries more readable. “Extract CRM data” is clearer than “Step 1” in a version comparison.
  • Rollback early. If a pipeline starts failing after a change, rollback to the last known working version while you investigate. You can always create another version with a fix later.
  • Check version history before modifying shared pipelines. If another team member has made recent changes, review their versions before overwriting.

Next steps