Tres Seaver <tsea...@palladion.com> writes: > Ross Patterson wrote: >> Tres Seaver <tsea...@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*.
Thanks, that's exactly what I wanted to hear. So it's not so much about being inherently easier to implement as it is about enabling the removal of code. In that case, I'm +1 on this but I have other concerns. > 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). It seems like this this dump format will likely become a point of hackability in our software ecosystem. People out there will find interesting things to do with it aside from dump-and-reload. This would be a good thing except we're *expecting* the format to be unstable and change rapidly. It seems possible that there would be some ruffled feathers out there amongst those who come to depend on such hacks and then find that their favorite hack is quickly broken by the next release. As such, it seems like it would be a good idea to dress up the dump format in flashing red lights and loud alarms to discourage at least the adoption of such hacks if not their creation. It also seems like the complexity of this dump format is easily underestimated. I'm a little concerned that we'll adopt a solution that is more accidental in nature, such as an extension to the current GS handlers. I suspect that later we'd find some structural inadequacies in such an approach but having already build our upgrade machinery around it we'll have yet another painful change to make as we change to something better designed. OTOH, perfect is the enemy of good enough. I suggest we start with a *minimal* design discussion about how to architect a dump-and-reload strategy with the future in mind. Ross _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
