Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[gmt-dev] Fw: [gme-users] Please Fix Versioning Hell!

Thought it worthwhile to cross-copy us on this post, see below.

1. We should bear the GME versioning approach/issues in mind when
integrating GME with GMT
2. Some important lessons for the development of GMT. GMT's role of an MDA
tool orchestration component means that we can't afford any of the
versioning issues illustrated below.

Jorn

Jorn Bettin
jorn.bettin@xxxxxxxxxxxxxxxx
www.softmetaware.com
Tel  +64 9 372 3073 | Mobile +64 27 448 3507 | Fax +64 9 372 3534

----- Original Message -----
From: "Gabriele Trombetti" <gabtromb@xxxxxxxxxxxxxxxxxxx>
To: "gme-users" <gme-users@xxxxxxxxxxxxxxxxxxxxxxxx>;
<udm-users-request@xxxxxxxxxxxxxxxxxxxxxxxx>; "GReAT-users"
<great-users@xxxxxxxxxxxxxxxxxxxxxxxx>
Sent: Sunday, May 30, 2004 10:33 AM
Subject: [gme-users] Please Fix Versioning Hell!


> With the following story, I'm trying to pushing for efforts to be made
> to reach an agreement which could allow various versions of GME, UDM,
> GReAT, OTIF interoperate.
>
> -------
>
> I'm working on a conversion between PICML (a GME project made here in
> Vanderbilt) format to an XML format that reflects Cadena
> (http://cadena.projects.cis.ksu.edu/) project structure and vice versa.
>
> I'm working with GReAT for this conversion, and the resulting XML is to
> be published on the OTIF backplane.
>
> My work has become _incredibly_ difficult lately, because of the
> interface versioning problems of GME (primarily) and UDM, GReAT, OTIF.
>
> In the beginning we (PICML developers) were using GME3.10.13 .
> At first my conversion project was not feasible because the GReAT 1.2.3
> was using an UDM version which did not allow me to create subtypes and
> instances of a model, and this was absolutely a requirement for PICML.
>
> The newer version of UDM (2.14.2 unofficial) could do that. With almost
> every other development tool I know, this would just mean overwriting
> the current UDM with the new UDM 2.14.2 and going ahead. But instead
> this new UDM would not work with GReAT 1.2.3 nor GME3.
> So I had to ask Adi to build an unofficial version of GReAT with UDM
> 2.14.2 for me. At that point it worked, but that version was running for
> the latest released GME which was GME4.3.17 .
>
> So I had to detach from the other PICML developers which were still
> working with GME3, and migrate my copy of PICML metamodel to GME4.3.17
> (also in the repository now we have 2 versions: the official one, and
mine)
>
> Our clients (sponsors) also had problems because in order to use my
> transformation they had to uninstall GME3 (and possibly UDM), install
> GME4.3.17, install GReAT and UDM and perform the transformation.... And
> then go back uninstalling everything and reinstalling GME3 which was the
> platform of choice for working with PICML. A bit a tedious job for just
> performing an export of their model to Cadena!
>
> Then additional problems came:
> For my project I need to publish the xml file (output of GReAT) onto the
> OTIF backplane. A version of OTIF for GME4 doesn't exist yet. Zsolt
> built an unofficial one for me, but that one was using the latest UDM
> which is 2.16 and only works with GME4.5.18, while the latest version of
> GReAT (which is mine) works only with UDM 2.14.2 and GME 4.3.17 .
>
> So I still could not use OTIF and GReAT together; and to swap from one
> to the other required some 30 minutes of uninstalling and reinstalling
> the whole world.
>
> Then Kitty found that there were a few serious bugs with the code
> generation in all the available versions of UDM, which would make all
> the C++ generated code impossible to compile for PICML. This also
> affected ME but I hadn't tried to compile the GReAT generated code until
> then.
>
> The fixes in UDM have been promptly made by Zsolt, but now we have to
> upgrade! Oh Zeus, what will happen now? We will have to ask the GReAT
> team to make a new release of GReAT with this new UDM, and the OTIF team
> also! The GReAT and OTIF teams in general are not always in sync and
> ready to make a release for every version of UDM and GReAT that comes
> out, anytime! They might have big changes ongoing, which means that
> their code might not even compile at that time.
>
> Now we have 3 softwares: UDM, GReAT, OTIF; and as soon as we find a
> show-stopper bug in one of them we have to ask to THREE teams to rebuild
> their software before we can go ahead with our project!
>
> And most of those versions I have written about have not been officially
> released, which means that our sponsors currently are not even able to
> access our work! What do we tell them?
>
> I have never seen such a versioning hell happening before. I'm not sure
> where it comes from, but sure it has to be fixed as soon as possible.
>
> I suspect it starts from GME and it's COM interfaces. Well, wherever you
> read about COM, you will read that COM was made in such a way to REDUCE
> the versioning problems, not to increase them.
>
> AFAIK with COM it is possible to inherit the interfaces, like in CORBA,
> right? Then please GME folks, keep the old interfaces available and make
> the variations on new derived interfaces. Who cares if you need to
> increase the GME size by 200K every new version because you are keeping
> the old interfaces and a part of the old code for backward
> compatibility, this is *normal* when making software.
>
> At least you have to maintain compatibility within the same major
> version number; this is what the major version number is for, isn't it?
>
> Then I don't know what other fixes are needed but I suggest that the 4
> leading teams (GME, UDM, OTIF and GReAT) should meet together *soon* to
> start ensuring inter-version compatibility.
>
>
> Thank you
> Gabriele Trombetti
> _______________________________________________
> gme-users mailing list
> gme-users@xxxxxxxxxxxxxxxxxxxxxxxx
> http://list.isis.vanderbilt.edu/mailman/listinfo/gme-users
>




Back to the top