Should you install a prerelease? Alpha, latest, pinning

The question is not whether you dare, but whether the benefit is clear and rollback is possible. Both conditions must hold; if either fails, stay on stable.

Three sources

A prerelease can arrive from three places; identify yours first.

Releases are the most readable. They usually carry changelogs and known issues, the first-hand material for judging whether a build is worth it (source).

Read npm tags carefully. The version a tag points at can change, and depending on a tag makes results unreproducible.

Branch builds are for developers. They are newest and easiest to break; daily use should not follow a branch.

Four conditions before upgrading

All four should hold before you consider it.

1. Clear benefit: it fixes a problem you actually have or provides a needed feature.
2. Acceptable risk: you have time to handle fallout and are not in a critical delivery window.
3. Rollback possible: version recorded, data backed up, old build still installable.
4. Verifiable: a minimal feature checklist exists to judge health quickly.

Do not upgrade without a clear benefit. "It might be better" is not a reason; the cost of a prerelease is diagnosis and rollback.

Rollback ability is the floor. An upgrade with no way back is a bet on the whole environment.

Preparation

Five minutes of preparation saves an hour later.

1. Record the current core version and plugin list.
2. Back up configuration and session directories.
3. Confirm the target version number and installation method.
4. Prepare a minimal checklist: startup, a session, one plugin.
5. Choose a non-critical window for the change.

Record versions so you can roll back. "The old one" is useless; you need the exact number.

A backup must be restorable. Verify the directory structure once, so you do not discover it incomplete when needed.

Upgrade and verification

The action is simple; verification must be specific.

1. Install the exact target version, never latest.
2. Start the service and confirm the version reported.
3. Run one minimal conversation to confirm the model works.
4. Open a plugin and confirm it loads.
5. Read logs for new errors or compatibility warnings.

All four checks passing is what counts as success. Looking only at the splash screen can hide a failed plugin.

Keep the checklist fixed. The same set each time makes results comparable; improvising items invites omissions.

Rollback and pinning

Rollback must be fast; pinning must be steady.

1. Rollback command: reinstall the exact version, not latest.
2. Restore data: replace the data directory from backup when needed.
3. Pin the version: once verified, write the number to block automatic upgrades.
4. Record the outcome: which build worked and which did not.
5. Plan the next move: evaluate switching after a stable release lands.

Rollback is not reinstalling latest. That can land you back on the broken build; specify the target version.

Pinning is a long-term policy. Run verified versions and upgrade on a plan; following latest suits personal experiments only.

When not to upgrade

Three situations make a prerelease a bad trade.

1. Critical delivery window: no time to handle fallout.
2. No rollback path: the old build is unavailable or data is incompatible.
3. Unclear benefit: you just want to try something new.

All three share a risk greater than the reward. Upgrading is not the goal; solving the problem is.

Stable first in production. To validate a fix, run the prerelease in a test environment and plan the change after confirmation.

Next steps

Check benefit, then rollback, then upgrade. For version numbers and tags, read How to read DeepSeek Harness versions. For dist-tag installs, read Prerelease versions and dist-tags. For pinning, read Version choice and pinning.

Sources: DeepSeek Harness releases, dsh CLI README, deepseek-harness repository