the first is a more general plugin command, using the CN value of the plugin name, should be consistent between releases, but can be easily customized in the dse.ldif config file when an instance is deployed.
the second is dedicated to the "specific" plugins, it is a more recent Python code, the class is called retrochangelog, but the sub command is called retro-changelog, this should also stay consistent.
just 2 different ways to do the same thing, with more control in the second form for those special plugins.
if this is about enabling or disabling a plugin, may be the first form is better,
for managing particular features of the special plugins like memberof, automember, referential-integrity, and some others, use the second form, or the cockpit web UI.
there were a few changes in March 2019 , some cosmetic, to have the "dedicated/special" plugins sub commands more consistent and more readable using the same format with a dash when they have composed words:
Issue 50041 - Add CLI functionality for special plugins
like
cmdName="retrochangelog"
cmdName="retro-changelog"
this is an active project, and the Python CLI was subject to more disruptive changes in 2019 than today when it was really new, with version 1.4.0, before the RHEL-8 introduction in May 2019, not as stable as now,
it was likely the right time to have this change.
and not subject to change anytime soon.
is it possible a 389-ds-base-1.4.0 from before March 2019 till lurking around?
Cordially,
Marc S.