Hi
I would prefer a unique stable, fixed "base" installer and a patcher for each next change, even if there will be a lot of patchers before a new "base" installed may be released.
The "base" installer wiould do its work (install the base version) and then would apply each patch he can found or on the server.
This scheme adds a few difficulties:
- each patch is more complex to write. He must check first if all requirement are ok, and then skip or apply. But this can be simplifyed by a patche engine, ech patch becoming more a "description" of what to do.
- the patches must be named with sequence number including version they generate to ensure dependencies
- each patch must be documented about what it does.
- it may require to handle dependencies between patches for patch that do large change like database update
- it does not remove completely the need of a new installer, time to time when the number of patch is large enough
But it have a lot of more advantages:
- the installer is stable and does not evolve along life of major release number
- a patche would touch only the few things, so most of the time iit can apply without destroyng customised installs
- a patch can always be applyed again in case of skiped at a moment, even without effect
- a patch can be individualy skipped by an admin whom does not want it
- updates are always compatible, with all installed versions : only apply all patches existing from this version to go up to the last .
- it enables to have the panel more modular on install : module can become a patch. ie everything concernig nameserver can be setup by a patch.
- the patcher engine can be written with ability to reverse a change done by a patch, enabling very high level of safe.
I would prefer a unique stable, fixed "base" installer and a patcher for each next change, even if there will be a lot of patchers before a new "base" installed may be released.
The "base" installer wiould do its work (install the base version) and then would apply each patch he can found or on the server.
This scheme adds a few difficulties:
- each patch is more complex to write. He must check first if all requirement are ok, and then skip or apply. But this can be simplifyed by a patche engine, ech patch becoming more a "description" of what to do.
- the patches must be named with sequence number including version they generate to ensure dependencies
- each patch must be documented about what it does.
- it may require to handle dependencies between patches for patch that do large change like database update
- it does not remove completely the need of a new installer, time to time when the number of patch is large enough
But it have a lot of more advantages:
- the installer is stable and does not evolve along life of major release number
- a patche would touch only the few things, so most of the time iit can apply without destroyng customised installs
- a patch can always be applyed again in case of skiped at a moment, even without effect
- a patch can be individualy skipped by an admin whom does not want it
- updates are always compatible, with all installed versions : only apply all patches existing from this version to go up to the last .
- it enables to have the panel more modular on install : module can become a patch. ie everything concernig nameserver can be setup by a patch.
- the patcher engine can be written with ability to reverse a change done by a patch, enabling very high level of safe.
