It is enough to change this to cover fixes, 3.2.3, and a future 3.2.4:
{$IF FPC_FULLVERSION >= 30203} // change here to 3.2.x fixes
{$DEFINE WITH_FTSINGLE}
{$DEFINE WITH_FTSHORTINT}
{$IFEND}
Regards,
Thaddy
On 2025-04-01 14:50, Michael Roland via fpc-devel wrote:
Ok, thanks for explaining. I am new to Free Pascal.
What is the best way to check which version of TFieldType is in use?
Is the compiler patch number changed when changes like this occur? Is
there a more reliable method than looking at the compiler version?
-------------------------
From: fpc-devel <fpc-devel-boun...@lists.freepascal.org> on behalf of
Marco van de Voort via fpc-devel <fpc-devel@lists.freepascal.org>
Sent: Tuesday, April 1, 2025 5:45 AM
To: fpc-devel@lists.freepascal.org <fpc-devel@lists.freepascal.org>
Cc: Marco van de Voort <f...@pascalprogramming.org>
Subject: Re: [fpc-devel] Wrong version of db.pas in the fixes_3_2
branch?
Op 1-4-2025 om 08:04 schreef Sven Barth via fpc-devel:
Are any other files from the 3.3.1 branch in the fixes_3_2
branch?
There are no "files from the 3.3.1 branch" that were moved over
(well,
expect maybe some new ones), just selected changes that were merged
over. This is simply how things work and third party software has to
adjust their checks. That's how it has always been.
As Sven says, the fixes branch is a mix of development-at-arms-length
and a rigid stable branch(as in bugfix only). In practice it means
that
compiler changes are usually real bugfixes (the rigid part), but
runtime
and library changes and fixes are merged when they are considered
stable
(the development-at-arms-length part) and don't depend on new language
features.
The criterium is mostly that the merges must be possible without too
much hand interference (which could possibly introduce bugs due to the
merging), in the past there have been exceptions to that for specially
major Mysql versions.
New mysql major versions are also one of the main reasons why also
features are added, otherwise you could now only use 6 year old
mysql/mariadb versions (not that it is much better with the current
fixes release frequency)
A few attempts were made at also providing wholly rigid stable
branches
for e.g. corporate use, but those initiatives to my best knowledge
petered out.
The reasons are rooted in release frequency, but also spreading out
library fixes more to avoid the dreaded "don't use .0 versions"
syndrome
by mitigating the amount of changes in library code that hasn't seen
wide usage yet in new major (.0) releases.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
CAUTION: This email originated from outside of Ocmulgee EMC! Do not
click links, open attachments or reply, unless you recognize the
sender's email address and know the content is safe!
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
