The list of plugin version being shown when running spin plugins list is really long. I'd like to propose changing it to only show latest version (and installed version of a given plugin, if it's not the latest).
Current
trigger-command 0.1.0
trigger-command 0.2.0
trigger-command 0.2.1
trigger-command 0.2.2
trigger-command 0.3.0
trigger-command 0.3.1
trigger-command 0.3.2
trigger-command 0.4.0
trigger-command 0.4.1
trigger-command 0.5.0
trigger-command 0.5.1
trigger-command 0.5.2
trigger-command 0.5.3
trigger-command 0.6.0
trigger-command 0.7.0
Proposed
trigger-command 0.6.0 [installed]
trigger-command 0.7.0 [latest]
Having had conversations with LLMs there's an option to do a strict migration or soft deprecation of default behavior with the existing --summary flag.
Strict cutover with --all kept
New default: spin plugins list shows latest only.
--all means show all versions (same name as today).
Remove --summary entirely.
No compatibility aliasing.
Impact:
Users relying on default output (all versions) will see changed behavior.
Users already using --all in scripts should continue to work with little or no change.
Soft migration with --all kept
Same new default: latest only.
Keep --all for all versions.
Keep --summary temporarily as deprecated (hidden or warned) for one release cycle.
Optionally print deprecation warning when --summary is used.
Impact:
Minimal disruption for users who learned/used --summary.
Easier comms and rollout, then remove --summary later.
What this means compared to renaming to --all-versions
Keeping --all removes one migration burden: no need to teach a new flag name.
Most compatibility work shifts to handling --summary only.
In practice, strict vs soft mostly becomes:
Strict: remove --summary now.
Soft: deprecate --summary, remove later.
Recommendation
Keep --all and do soft migration if you want lowest user friction.
Keep --all and do strict cutover if you want the cleanest CLI immediately and can tolerate minor breakage for --summary users.
I'd like some feedback on which path to go down - soft or strict. Thanks.
The list of plugin version being shown when running
spin plugins listis really long. I'd like to propose changing it to only show latest version (and installed version of a given plugin, if it's not the latest).Current
Proposed
Having had conversations with LLMs there's an option to do a strict migration or soft deprecation of default behavior with the existing
--summaryflag.Strict cutover with --all kept
New default: spin plugins list shows latest only.
--all means show all versions (same name as today).
Remove --summary entirely.
No compatibility aliasing.
Impact:
Users relying on default output (all versions) will see changed behavior.
Users already using --all in scripts should continue to work with little or no change.
Soft migration with --all kept
Same new default: latest only.
Keep --all for all versions.
Keep --summary temporarily as deprecated (hidden or warned) for one release cycle.
Optionally print deprecation warning when --summary is used.
Impact:
Minimal disruption for users who learned/used --summary.
Easier comms and rollout, then remove --summary later.
What this means compared to renaming to --all-versions
Keeping --all removes one migration burden: no need to teach a new flag name.
Most compatibility work shifts to handling --summary only.
In practice, strict vs soft mostly becomes:
Strict: remove --summary now.
Soft: deprecate --summary, remove later.
Recommendation
Keep --all and do soft migration if you want lowest user friction.
Keep --all and do strict cutover if you want the cleanest CLI immediately and can tolerate minor breakage for --summary users.
I'd like some feedback on which path to go down - soft or strict. Thanks.