Comment 2 for bug 1302656

Revision history for this message
Michi Henning (michihenning) wrote :

When the scoperunner initialises a scope, it checks the version. If the version of the scope doesn't match the scoperunner's version, the scoperunner bails out with an appropriate message.

But I agree that we have a problem as it stands because, if we deploy a new version of our library, all existing scopes will break until they are recompiled and and redeployed.

Here are some thoughts:

We would need to keep multiple copies of the scoperunner around. Not sure what the implications are for packaging and installing upgrades. If someone upgrades the scopes infrastructure from, say, 1.0.0 to 2.0.0, would it be possible to leave the previously-installed libs and scoperunner binary behind? Or would we include the version 1.0.0 binaries and library in the 2.0.0 release?

If the latter, how would we manage this for our build environment once we start working on version 2? Exactly how would we ensure that older binaries and libs either get recompiled from the then-current sources and get included in the 2.0.0 package? How would cmake cope with this?

Or would we keep the old binaries around as binary blobs somewhere inside the source tree to be added to the 2.0.0 package? How would this interact with multi-arch?

For the scoperunner itself, we could have a "wrapper" scope runner whose job it is to identify what version is needed by a particular scope and then exec the version-specific scoperunner accordingly.

How does the scoperunner know what version is needed? It could just load the shared lib for the scope, retrieve the version number, and then make a decision accordingly. This is somewhat expensive, but probably preferable to requiring the scope author to add a version number to the scope's .ini file. (I expect that doing this would turn out to be brittle and error-prone.)

There is also the issue of config files. Over time, we will certainly add new config items, and quite likely deprecate some. At the very least, the config machinery would have to tolerate unknown settings (which it does, currently, with a warning).

Opinions?