The application data file format is not being changed at all and a lot of effort has been put into the file I/O logic to support all previous Open/GnuCOBOL file formats as well as most Microfocus file formats.
If the libcob.so.N is bumped then an install of the new compiler would not replace the old libcob.so.N and only old binaries should still load the old libcob.
So as long as we can bump the value of N in libcob.so.N there should be no problem.
However, if I did have to recompile all of my COBOL code that is not much of a hardship. I would just kick off 'make' and go for a coffee.
On Mon, Jan 20, 2020 at 1:13 PM James K. Lowden <jklowden@xxxxxxxxxxxxxxx> wrote:
On Sat, 11 Jan 2020 13:15:44 +0100
Simon Sobisch <simonsobisch@xxxxxxx> 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
Cheers
Ron Norman
