Skip to main content

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

This is indeed an interesting horror story. It is also extra reason to stick
to a common intermediate format, such a Ecore and XMI. In that case there
will always be just one point of change.

Regards,
Ghica van Emde Boas
Bronstee.com Software & Services b.v.
e-mail: emdeboas@xxxxxxxxxxxx,
tel: +31 23 5474422,
or: +31 6 53368747 (mobile)
fax: +31 23 5473347


> -----Original Message-----
> From: gmt-dev-admin@xxxxxxxxxxx [mailto:gmt-dev-admin@xxxxxxxxxxx]On
> Behalf Of Jorn Bettin
> Sent: Monday, May 31, 2004 12:22 AM
> To: gmt-dev@xxxxxxxxxxx
> Subject: [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
> >
>
>
> _______________________________________________
> gmt-dev mailing list
> gmt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/gmt-dev
>
> --
> This message has been scanned for viruses and dangerous content
> by MoveNext MailScanner, and is believed to be clean.
>
>




Back to the top