Upgrade order for dsh-plugin-hub and the core

The upgrade order for dsh-plugin-hub and DeepSeek Harness follows the dependency direction, not the release calendar. The Hub is a plugin that consumes core capabilities, so the core can move first when the Hub declares support for the new range. Reversing that order is a rehearsal, not a default.

How dsh-plugin-hub depends on DeepSeek Harness

The Hub consumes APIs and fields that the core provides, so compatibility is declared by the dependent side.

The core owns the runtime, the session model and the interfaces that plugins call. It can add a field or change a route without knowing which plugins exist. That freedom is why the core can move first when the dependent plugin has already tested the new range.

The Hub owns the market interface and the way entries are rendered. It reads what the core sends and turns it into categories, cards and detail views. When the core changes a shape, the Hub is the side that must adapt.

This direction is easy to remember because it matches the install graph. The Hub is installed into a core environment, not the other way around. A core installation without the Hub is a normal setup, while a Hub without a compatible core is a broken one.

The practical consequence is that the core is the stable base and the Hub is the moving edge. Upgrade the base when the edge has announced support. Upgrade the edge when it needs a capability that the base already provides.

Reading the version lines behind a DSH plugin upgrade

Two numbers, one for the core and one for the Hub, describe the whole compatibility state.

The core version appears in the CLI and in the client about screen. The Hub version appears in the installed plugin list and on the market entry. Keep both in the same note, because a note with one number cannot explain a failure.

The table is not a rule about which number should be larger. It is a map of blast radius. A core mismatch reaches DSH plugins that never touch the market, while a Hub mismatch usually stays inside the market panel.

Read the compatibility statement on the DSH Plugin Hub entry or in the repository before acting. A declared range is evidence, and its absence is a warning that the combination is untested. Do not infer support from the fact that both packages are recent.

When the DeepSeek Harness core should move first

Core first is the default when the Hub has already declared support for the new core range.

Start by confirming that declaration, because an untested core upgrade can break every plugin on the machine. The entry or release notes should name the supported range, not just the latest version. If the range is missing, treat the upgrade as an experiment.

Record the current pair before changing anything. The old core version and the old Hub version are your rollback coordinates, and they are much harder to reconstruct after the fact. A single line in a notes file is enough.

Upgrade the core and verify the core paths before touching the Hub. Start a session, open a project and confirm that ordinary work still behaves. If the core is unstable, the Hub upgrade will confuse the diagnosis rather than improve it.

Then upgrade the Hub and confirm that the market opens and entries load. A core-first sequence gives you two clean checkpoints instead of one mixed state. That separation is the main reason to prefer it when support is declared.

When a dsh plugin hub upgrade should lead

A Hub-first upgrade belongs in a rehearsal environment where the new market can be tested against the current core.

Read the Hub release notes and look for a required core version. If the Hub expects a newer core, installing it on the old core will demonstrate the failure rather than prevent it. That can be useful, but only when you are deliberately testing.

Use a machine or profile that nobody depends on for daily work. Install the new Hub, open the market and watch for unknown fields, missing categories or rendering errors. Write down each symptom with the action that produced it.

Then upgrade the core and repeat the same actions. If the symptoms disappear, you have confirmed the dependency and learned what the mismatch looks like. If they persist, the problem is probably inside the Hub rather than in the version pair.

A Hub-first run is not a production strategy, because users see a broken market while you learn. It is a controlled experiment that produces a compatibility note. Keep it out of the normal upgrade path.

Recording a DeepSeek Harness plugin combination

A written combination turns a successful upgrade into evidence that the next upgrade can reuse.

Write the core version, the Hub version, the date and the paths you tested. Include the market, a detail page, an install action and a normal session. A version pair without tested paths is only a guess about compatibility.

Record failures as well as successes, because a failed pair tells you which order to avoid. The note should say which line moved first and which symptom appeared. That detail is what makes the record useful during an incident.

1. Write down the core version before the upgrade starts.
2. Write down the Hub version before the upgrade starts.
3. Note which line you upgraded first.
4. Test the market list and one plugin detail page.
5. Test an install action and a normal session.
6. Record the symptom of any failure with the action that caused it.
7. Add the date so an old result is not mistaken for current evidence.

The list is short on purpose. A record that takes ten minutes to write will not survive a busy week, while four lines can be updated every time. Consistency matters more than detail here.

Keep the old release packages next to the note. A rollback should not require a search through release pages while users are waiting. The note tells you what to restore, and the package makes the restore possible.

What the right dsh plugin upgrade order protects

Order protects the ability to explain a failure, which matters more than finishing the upgrade quickly.

A core-first sequence with a declared Hub range gives you two checkpoints and a clear owner for each symptom. A Hub-first rehearsal gives you a controlled view of the mismatch without exposing daily users. Both are honest about which side depends on which.

The wrong order does not always break immediately, which is why it survives in teams. A newer Hub can work for days before a field appears that the old core never sends. By then the upgrade is old news and the connection is hard to see.

Treat the compatibility statement as the authority and the release date as irrelevant. A slightly older Hub that supports the new core is safer than a newer Hub that does not. The version pair, not the calendar, decides the order.

Write the pair down, test the paths, and keep the old packages. That routine turns upgrade order from a debate into a repeatable decision, and it keeps the market and the core from surprising each other. The next upgrade then starts from evidence instead of from a guess about which release is newer.