[gme-users] Please Fix Versioning Hell!

Peter Volgyesi peter.volgyesi at vanderbilt.edu
Tue Jun 1 14:37:29 CDT 2004


Hi,

I agree with all GME users who feel it painfull to use GME _and_ dependent
tools together.

Unfortunatelly, I can't see a clear solution if one is using the native (not
the dispatch based) interfaces (like UDM).
Gabriele suggested to inherit new COM interfaces and classes on every minor
changes. If you ever used COM in practice, you might know that this would be
a real pain in the back (it should work in large software companies, but
unfeasible with our current development  model):
- creating a new (inherited class) requires new interfacename, GUIDs,
registry entries, etc. It is far from straightforward.
- in all over the code (inside GME) we should make sure that we are using
the latest version of a given interface (eg.: IMgaFolder29)
- it would allow strict incremental changes only
- for COM method parameters it would be hard to decide which interface to
use/accept (eg.: IMgaFolder29 or IMgaFolder6)

I'm afraid, the situation might grow much worse than current version
conflicts.
As Gabriele said, COM was _supposed_ to reduce versioning problems. It
failed. It is no surprise that MS took a very different approach in .Net. It
is also no surprise that for MS products, like the office tools the company
did not disclose the native COM interfaces, we have to use automation
instead.

The versioning problem could be solved if all our tools were open source
(eg.: for a given release label one could get and build a package), since
most of the version conflicts affect the compiled binary programs only.
--
peter
 



More information about the gme-users mailing list