[Framework-Team] Re: [plone4] Release process

Tres Seaver tseaver at palladion.com
Sat Dec 27 17:52:12 UTC 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ross Patterson wrote:
> Tres Seaver <tseaver at palladion.com> writes:
> 
>> Hanno Schlichting wrote:
>>
>>> - Plone 4 will have a documented upgrade story
>>>
>>> A migration from Plone 3 to 4 does not need to be possible in an
>>> almost fully automated fashion. We need to ensure we have an easy to
>>> follow and understandable documented upgrade story. If we for example
>>> change API's or rearrange code, we can document the new places in
>>> writing and with error references for the most commonly used
>>> parts. If you need to change your buildout configuration, a document
>>> explaining the changes is fine, we don't need to build an upgrade
>>> machinery for configuration files.
>> Can I persuade you and the FWT to forego an "upgrade-in-place"
>> strategy for moving from P3 to P4, and instead to have a well-tested
>> ad documented "dump-and-reload" story?
> 
> I've never actually understood how a dump-and-reload approach would be
> inherently more maintainable or otherwise more trouble-free.  I know
> this has been discussed before, but I missed those discussions.  Can
> anyone shortcut the research for me and give me some links or pointers
> to previous discussions?

The short answer is that in-place migrations lead to ordering-dependent
arrangements of crufty bits in the site:  it gets particularly bad when
the representation format of the data changes.  If the programmer is
both careful and lucky, she can often mitigate the problem with clever
defaults, properties, etc., but the downside is that the BBB-driven code
has to stay around *forever*.

In SQL land, you can imagine altering tables to add columns, etc., with
out breaking anything (assuming that sensible defaults exist).  However,
if the original low-level partitioning / indexing algorithm changes,
etc., then dump-reload is the only sane way forward.  It is pretty much
standard practice to do dump-reload in enterprise-scale RDBMS
applications whenever upgrading the RDBMS software itself.

Dumping the content out to a "neutral" format and loading it into a
"clean" site loses the crufty bits, and leaves the code in the "new"
software free of nasty BBB stuff.  It also gives people a migration
target (for moving content into Plone, or even out of it), as well as a
non-ZODB-specific backup representation of the site (e.g., to populate a
staging / testing server).


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJVmtM+gerLs4ltQ4RAg29AKChL3bYfEI7NbcISkA7rnfOoVJRoQCgiB92
fpUDM0LadK3U4++MvGd93Mw=
=UIzF
-----END PGP SIGNATURE-----





More information about the Framework-Team mailing list