koen wrote:

In the 7.6 and beyond thread JT mentioned in reply to a message from cap10morgan:

However, I will say that everything you're proposing here is stuff that we are accounting for in the new LIFT upgrade system that we're designing. We wanted it to go into 7.5, but that's not going to happen now, so it will be 7.6 or later instead.

I think I heared something on IRC about this system from Doug.

What is the LIFT upgrade system?

What does LIFT mean?

I'd like to know more about it and participate in its creation.

Koen de Jonge - ProcoliX
http://www.procolix.com
Hosting - WebGUI - Virtualization

http://www.plainblack.com/webgui/dev/discuss/lift-upgrade-system

--

Plain Black, makers of WebGUI
http://plainblack.com

Unfortunately Lift got killed before it got started just due to lack of developer resources on our part (all our developers have been working on client projects). Therefore we don't have a specification document yet. We only have two things so far: 1) This is our basic requirements list:

• It must be patch based so that it can incrementally apply code changes, and then run data patches against that code.
  
• It must not be tied to WebGUI, that way it can also upgrade WRE or any future products as well.
  
• It must be written in Perl so that it's easy to maintain and is cross-platform compatible (it must work the same on Windows as it does on Unix)
  
• It must provide an HTTP based API for browsing and downloading patches, both by humans and machines.
  
• It must provide a client side library API so that command line, GUI, and automated provisioning system programs can be written against it.
  
• Lift must be able to patch itself.
  
• It must be have pluggable handlers so that it can apply patches of different types. For example code/diff based patches, perl programs, shell scripts, sql files, etc.
  
• It must gracefully handle customization by users, stopping when it finds customizations that it can't handle so that they can be worked out by the user, and then continue on with the upgrade.
  
• The human web interface must allow download of an archive of patches so that users not connected to the internet can download patches to apply offline.
  
• The command line interface must allow execution of patches that don't come from the machine web interface so that patches can be applied offline.
  
• It must handle "channels" so that it can maintain patches for multiple products. Lift, WRE, and WebGUI being the first three.
  

It was born out of a desire to put an end to the need for "Upgrade Steps", versions that you must upgrade TO before you can upgrade BEYOND. After much discussion, we decided we could use unified diffs to achieve this.

Then it began growing into a full-featured way to manage WebGUI installations, since we do custom code work for clients and Lift would need to understand (and perhaps help). It would also have to gracefully handle all the things that other people do to WebGUI (which is an improvement over our current methods).

Then we thought if we were going to spend so much time on something, we may as well make it as agnostic as possible, so not dependent or limited to just WebGUI.

And then it got complicated... (if you're going to do three impossible things, why not add more?)

LIFT is one of those things that hackers beg for: A project that pushes the boundaries of what is possible.

I propose a backronym contest to find out what LIFT means:

Loosely Integrated Feature Teacher?

Low-Impact Functionality Technology?

Laymen In Future Transitions?

Lightweight Integrator of Future Technology?