Actually, changing from the previous comments on [6], nevermind
regarding the command name suggestion. upgrade-formula sounds fine
as a way to disambiguate from "upgrade the software/packages".
But then:
[8]
+After the newer formula is in place and before any hooks are executed
+from it, the unit agent will execute the ``upgrade`` hook on the unit
+if present.
Let's name the hook as "upgrade-formula", to match the command name,
and let's reserve the "upgrade" name for package/software upgrades.
[9]
+This allows the formula to process any upgrade concerns it may have
+with regard to upgrading databases, software, etc before its new
+version of hooks are invoked.
We'll need a way to do pre-post logic. Maybe we need a
upgraded-formula hook too, which is executed *after* the new formula
is in place, and then the "upgrade-formula" one is executed *before*
the old one is removed.
Some additional comments, and a change re. [6]:
[6]
Actually, changing from the previous comments on [6], nevermind
regarding the command name suggestion. upgrade-formula sounds fine
as a way to disambiguate from "upgrade the software/packages".
But then:
[8]
+After the newer formula is in place and before any hooks are executed
+from it, the unit agent will execute the ``upgrade`` hook on the unit
+if present.
Let's name the hook as "upgrade-formula", to match the command name,
and let's reserve the "upgrade" name for package/software upgrades.
[9]
+This allows the formula to process any upgrade concerns it may have
+with regard to upgrading databases, software, etc before its new
+version of hooks are invoked.
We'll need a way to do pre-post logic. Maybe we need a
upgraded-formula hook too, which is executed *after* the new formula
is in place, and then the "upgrade-formula" one is executed *before*
the old one is removed.
What do you think?