Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Corrected links that should have been relative instead of absolute.

Status
implemented
14.2
implemented
See MAGNOLIA-2828@jira.
Status

(!)see NodeBuilder API concept page - Writing and maintaining update tasks is a error-prone and also boring task.

The Problem

The main problem is that we have to maintain the installation and update procedure separately. While we implicitly test the installation process we rarely do that for the update tasks.

It is very easy:

  • to forget an update tasks
  • write them wrongly (based on wrong assumption)
  • write them not fain grained enough because it is time consuming

Potential Solutions

Use a builder API

It is in general a good idea to code deltas / initial configuration by using a content builder API.

see MAGNOLIA-2828@jira

A) Do not separate Installation /Update

  • write the initial installation process
  • on later installations 1.0.3 execute the initial installation and the deltas
  • on update simply execute the deltas (as today)

This works as long the deltas are small enough. But there is a tricky thing to consider: that each module executes the complete chain and only then the next modules update tasks are executed. This can lead to unwanted side effects if one delta depends on a former state from an other module.

B) Generate the delta code

We could have a tool which can generate the update code (using the builder API) based on either two repository states or two bootstrap files.

  • this ensures that nothing gets forgotten
  • tasks are fine grained
  • easier to verify
    (minus) it's too easy to make mistakes by relying too much on such a tool (i.e. the tool can't know if a property has been renamed ("template" / "templatePath") or dropped and another one was added (i.e if it should keep the value or not)