2009/7/8 Peter Eisentraut <peter_e@gmx.net>:
> I have the following concern: Likely, this tool and the overall process will
> evolve over time. To pick an example that may or may not be actually useful,
> in the future we might want to change from a fixed list of patch sections to a
> free list of tags, say. Then someone might alter the application backend, and
> we'd use that new version for the next commit fest at the time. What will
> that do to the data of old commit fests?
Same thing that always happens when you make big-picture schema
changes to an app ... you either migrate the data or you leave a
historical instance in place.
NB moving from "topics" to "tags" is *not* a big-picture change and
wouldn't invalidate past data in the slightest.
> With the wiki, the data of the old fests will pretty much stay what is was,
> unless we change the wiki templates in drastic ways, as I understand it.
Actually the wiki makes this more difficult. Changes to the templates
are limited to adding new keyword arguments. If you want to, say,
insert a new positional argument into one of the templates, you need
to make a copy of all the affected templates and migrate all existing
template calls to the historical copy. We had to do this once. It
wasn't pleasant.
So, even for minor changes to layout (like the "tags" thing you
mentioned) result in having to leave a historical instance of the
system in place. Whereas having the data in a relational database
makes it far more likely that we can just migrate across small,
incremental changes.
Cheers,
BJ