[gme-users] Please Fix Versioning Hell!

[Gabriele Trombetti]

Peter Volgyesi wrote:

>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):
>  
>

I propose a slightly modified approach then:
You don't inherit & make a new interface every time you add a function, 
as I previously said, but only every major GME version number, and only 
for those interfaces that you effectively change.

Like this: in GME version 3 you had an IMgaFolder3 and IMgaMetaFco3. In 
version 4, say, you need to add something to IMgaFolder so you make an 
IMgaFolder4 but you don't need to add anything to IMgaMetaFco so you 
won't have a version 4 for that. In GME5.x.x, if you need to add 
something to IMgaMetaFco you will make a version 5 of that, inheriting 
from version 3, skipping version 4.

During the development of a GME major version, say GME4, you can make 
all the modifications you want to the interfaces version 4. Yes, you 
might screw the plugins which are using the very latest versions (4) of 
the interfaces (they should do that only if they really need the new 
functions!), but statistically I believe they are very few. I don't 
think even UDM is using any feature added in GME after GME3.

In your (GME) code you have a typedef which points to the latest version 
of every interface. So in your code when you write IMgaFolder, it will 
be an IMgaFolder4.

At any time you can change the implementation of any old or new 
interface (not semantically... typical scenario would be to fix a bug), 
but you are not allowed to change the idl of older versions.

This should keep the creation of new interfaces to a reasonable minimum. 
You have around 100 interfaces, I believe that you won't be inheriting 
more than 10-20 for every new major release of GME. It can take one 
man-day of extra work every major GME release for creating those 
inherited interfaces, but you will maintain binary compatibility with 
95% of the existing applications.

This is very IMHO. I have used COM only marginally: tell me if my 
estimates are wrong.

Let's see if they address all your points below here:

>- creating a new (inherited class) requires new interfacename, GUIDs,
>registry entries, etc. It is far from straightforward.
>  
>

Yeah correct but you would make say 20 new interfaces for every major 
GME release which happens every... how long... 8 months?
And the time would be spread across all that period because you create 
the new interfaces in the moment you need a new function, not all at the 
beginning.

>- in all over the code (inside GME) we should make sure that we are using
>the latest version of a given interface (eg.: IMgaFolder29)
>  
>
with the typedefs

>- it would allow strict incremental changes only
>  
>

Do you really plan to *remove* functions from the interfaces? Why is that?
Well anyway you could even do it by changing the implementation and 
throwing an exception like NotImplemented or Deprecated.
You would screw only those applications which really use THAT function 
(a big improvement from the current situation anyway), which might even 
be very few, expecially if that function was really not working correctly.

>- for COM method parameters it would be hard to decide which interface to
>use/accept (eg.: IMgaFolder29 or IMgaFolder6)
>  
>
You use the minimum interface number, among those which provide the 
maximum amount of information that you really USE inside your function. 
You can change the signature while you are in the same major GME 
version; when you switch major version number you freeze the signature.


Any comments appreciated
Thanks for your work
Gabriele