|
From: | Ron Norman |
Subject: | Re: [GnuCOBOL-Dev] Request for comment: trunk as GnuCOBOL 4, incompatible to previous versions? |
Date: | Mon, 20 Jan 2020 13:24:02 -0500 |
On Sat, 11 Jan 2020 13:15:44 +0100
Simon Sobisch <address@hidden> wrote:
> Also, we do have some "historical" burden because of the intended "you
> can switch to a new version without a complete recompile". The current
> most obvious part is the cob_file structure which was good when it was
> invented but the new version with reordered and extended arguments is
> both more "portable" and "easier to extend without the need to
> recompile in the future". We either "fall back to the old one" or
> have a very incompatible issue here.
I want to make sure I understand the issue, and state what I think is a
reasonable compatibility standard.
When he installs a new compiler and runtime library support (libcob),
the user may reasonably expect to be able to continue using his
programs and data files unchanged. The new library should not prevent
existing programs from working. That may be accomplished through the
SONAME of the library, causing existing programs to use the library
they were compiled for, and not the new one.
The new compiler should -- ideally -- not emit object code that cannot
read existing files. The user may reasonably expect that simply
recompiling his programs won't cause his files to become unreadable.
If the 4.0 version of the compiler cannot read files written by the 3.0
version, what is the user to do? At the very least, it seems to me, he
needs a free-standing utility to convert his files, else his data will
be lost. The work of providing that utility would probably be as great
or greater than including backward-compatibility in libcob.
If there's going to be a "hard break", we need to consider how old
programs will react to new files and how new programs will react to old
files. As a practical matter, ISTM it's likely the user will have a
mixture of new and old programs (compiled with 3.0 and 4.0) installed
and operating on the data concurrently.
--jkl
[Prev in Thread] | Current Thread | [Next in Thread] |