[fpc-devel] Wrong version of db.pas in the fixes_3_2 branch?

[thaddy]

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-bounces at lists.freepascal.org> on behalf of
> Marco van de Voort via fpc-devel <fpc-devel at lists.freepascal.org>
> Sent: Tuesday, April 1, 2025 5:45 AM
> To: fpc-devel at lists.freepascal.org <fpc-devel at lists.freepascal.org>
> Cc: Marco van de Voort <fpc at 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 at 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 at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel