[fpc-devel] Breaking change in FPC 2.6.1

[Tomas Hajny]

On Wed, May 2, 2012 12:27, Hans-Peter Diettrich wrote:
> Marco van de Voort schrieb:
>> In our previous episode, Hans-Peter Diettrich said:
>>> The solution is so easy: don't mark it as deprecated.
>>>
>>> I also have a clear opinion about Delphi compatibility: Every FPC
>>> version must be compatible to a Delphi version. A mix of incompatible
>>> features from different Delphi versions is useless.
>>
>> We don't have packages. That is what, D3? functionality, so we should
>> now
>> strip down FPC to D3 level?
>
> There exist *limitations* due to the FPC multi-platform approach, of
> course.

We cannot claim full compatibility to any Delphi version and we cannot
provide complete list of incompatibilities between any particular FPC
version and any particular Delphi version. If you're able to create
something like that, you're welcome to document and maintain it (e.g. in
our Wiki).

As far as what is more advantageous for users or not - your statement is
apparently based on certain assumptions which are probably not valid for
all FPC users and probably not even most FPC users. In particular, your
statement is fully correct for users extensively using almost all features
provided in a particular Delphi version and always rewriting their own
previous code (based on language constructs and units delivered with
earlier Delphi versions) to the newest set. In reality, users typically
combine code created for earlier versions with selected parts available in
newer versions depending on their needs and priorities. Users like this
will probably appreciate availability of a certain very new Delphi feature
regardless from the fact that certain older Delphi feature may not be
supported in FPC yet. For one, they may not use the older feature at all.
Even if they do, users like this still need to change less code on their
side if the newer feature is supported in FPC.

Even when talking about incompatibilities between two particular Delphi
versions, they may be less or more relevant/important for a particular
user depending on his needs. Some code may be perfectly shared between
pre-Unicode and Unicode based Delphi RTL without any changes and some code
needs to be rewritten almost completely. In summary, I personally believe
that majority of our users would not benefit from your proposal.
Nevertheless, you're free to create a special branches selectively merging
changes from FPC trunk based on their compatibility with specific Delphi
versions. Something like that may be useful for people creating components
and units targetting both FPC and Delphi users, but not necessarily for
others. In any case, Delphi releases do not drive FPC releases and I
personally believe that it is right that way.

Tomas