[Oorexx-devel] [DISCUSS] Release-to-release compatibility of the compiled image.

[Rick M. <obj...@gm...>]

So far, I've been able to preserve the forward compatibility of programs
that have been compiled with the rexxc utility.  Unfortunately, a big part
of maintaining this compatibility has been achieved by deferring some fixes
or enhancements because it will cause the image to break.  Originally, I'd
been working with a plan where the 3.x version would not be getting many
updates, and all of the work was going to go into 4.0, which would be such a
major update it was going to break the saved programs anyway.

Well, 4.0 was taking much longer than anticipated because of my move, and
development on 3.x was pretty stagnant.  Earlier this year I finally decided
that some of the enhancements that had been planned for 4.0 should be
implemented in 3.x and things really started to roll.  3.2.0 is a very big
release, and we're getting more people involved than ever before.  I'm
starting to think that rather than focus on the 4.0 mega release, I should
start migrating some of the enhancements from 4.0 back into the 3.x code
base, using a more incremental approach to doing this.  Some of the
enhancements we're already discussing (such as the ::CONSTANT changes) would
be best implemented in ways that would cause image compatibility anyway.

Key to this will be implementing some changes in 3.x that will be guaranteed
to break the programs compiled with an older version of rexxc.  And don't
even bother mentioning having a migration utility fix things up.  The
migration utility that exists only handled very minor migration
details...fixups of this size would not really be possible.  Some of the
updates I'd planned for 4.0 will make it easier to make updates without
breaking the compiled programs, which is a good thing.

So, I'm sort of proposing that we plan on the 3.3.0 release being a major
one that will not preserve the image compatibility.  I'll try to pull in as
many of the 4.0 "image breakers" as I can at this one release boundary,
including the changes that make it easier to maintain release-to-release
compatibility.  Some of these changes include changes to the object header
layout, an improved string hashing algorithm that will give better
performance, an improved mechanism for adding ooRexx internal classes, and
some of the 64-bit type cleanup changes.

Ok, fire away with your opinions.  A major break like this is inevitable.
Breaking now will make it easier to implement a lot of new features, and
potentially make it easier to move to the 4.0 release.  But if the breakage
is a major issue, then we'll just have to do the best we can until the focus
can get shifted to 4.0.

Rick