Maurits van Rees wrote:
The GS BBQ sprint branch looks promising. So we can probably drop this idea. But some (closing?) remarks are in order.
We seem to agree that this avenue is more interesting, so I'll only argue for the sake of principle (and argument) now. Please indulge me while I get a little argumentative, I do think this is an important debate to be having. ;-)
Migrations are complex things. They can have unintended side effects. They need to be easily testable. They need to be easy to debug.
All of those things tell me that it is an exceedingly (!) bad idea to rely on implicit introspection of names of things that people register (i.e. profiles) to determine what gets executed, when. It sound incredibly (!) fragile to depend on introspection of version strings, which can be based on nothing more than an assumption of conventions, to calculate an upgrade path.
It also sounds likely that relying on version strings would limit the vocabulary people can use to name their releases, in an arbitrary and potentially frustrating way, lest it leads to subtle bugs. It's exactly the kind of thing people end up "fighting the framework "for.
Conversely, it sounds error-prone to depend on abstract numbers that have no explicit relation to the names that people associate with versions. Migrations are about moving people between releases. Releases have names that are used widely (in the package name, in tarballs, in the cheese shop, on plone.org/products and so on). Having essentially two parallel concepts of a version (a released (or even unreleased) version string, and an abstract generation number) is surely unnecessary.
To control the order of execution of migration steps, I would much, much, much rather add an extra line of code, from which I could set a break point or add print statement or use some other debug technique. I would also much, much, much rather that the path consisted of things related to the releases that I make, so that I didn't need to remember to increment some integer or keep a big list somewhere of which generation integer related to each previous release, in case I had to go back and debug some intra-version migration in the past.
In my experience, introspection and inference may sound neat, are fun to code (but less fun to write tests for) for the framework writer, and feel like they save everyone a bit of work, but they usually end up costing a lot more grief in the long run. That's not to say we should make everything long-winded and spelled out in excruciating detail. A good balance in my mind, is to keep the locus of control in explicit, easily debuggable, easily testable code, and let convenience be a matter of defaults that can be explicitly overridden when necessary, rather than the default position.
Martin _______________________________________________ Product-Developers mailing list [email protected] http://lists.plone.org/mailman/listinfo/product-developers
