<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="appendonsend"></div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Ok, thanks for explaining. I am new to Free Pascal.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
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?</div>
<hr style="display: inline-block; width: 98%;">
<div dir="ltr" id="divRplyFwdMsg"><span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>From:</b> fpc-devel <fpc-devel-bounces@lists.freepascal.org> on behalf of Marco van de Voort via fpc-devel <fpc-devel@lists.freepascal.org><br>
<b>Sent:</b> Tuesday, April 1, 2025 5:45 AM<br>
<b>To:</b> fpc-devel@lists.freepascal.org <fpc-devel@lists.freepascal.org><br>
<b>Cc:</b> Marco van de Voort <fpc@pascalprogramming.org><br>
<b>Subject:</b> Re: [fpc-devel] Wrong version of db.pas in the fixes_3_2 branch?</span>
<div> </div>
</div>
<div style="font-size: 11pt;"><br>
Op 1-4-2025 om 08:04 schreef Sven Barth via fpc-devel:<br>
><br>
><br>
> Are any other files from the 3.3.1 branch in the fixes_3_2 branch?<br>
><br>
><br>
> There are no "files from the 3.3.1 branch" that were moved over (well,<br>
> expect maybe some new ones), just selected changes that were merged<br>
> over. This is simply how things work and third party software has to<br>
> adjust their checks. That's how it has always been.<br>
><br>
As Sven says, the fixes branch is a mix of development-at-arms-length<br>
and a rigid stable branch(as in bugfix only). In practice it means that<br>
compiler changes are usually real bugfixes (the rigid part), but runtime<br>
and library changes and fixes are merged when they are considered stable<br>
(the development-at-arms-length part) and don't depend on new language<br>
features.<br>
<br>
The criterium is mostly that the merges must be possible without too<br>
much hand interference (which could possibly introduce bugs due to the<br>
merging), in the past there have been exceptions to that for specially<br>
major Mysql versions.<br>
<br>
New mysql major versions are also one of the main reasons why also<br>
features are added, otherwise you could now only use 6 year old<br>
mysql/mariadb versions (not that it is much better with the current<br>
fixes release frequency)<br>
<br>
A few attempts were made at also providing wholly rigid stable branches<br>
for e.g. corporate use, but those initiatives to my best knowledge<br>
petered out.<br>
<br>
The reasons are rooted in release frequency, but also spreading out<br>
library fixes more to avoid the dreaded "don't use .0 versions" syndrome<br>
by mitigating the amount of changes in library code that hasn't seen<br>
wide usage yet in new major (.0) releases.<br>
<br>
<br>
_______________________________________________<br>
fpc-devel maillist - fpc-devel@lists.freepascal.org<br>
<a href="https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel" id="OWAbe07f918-8301-4021-5969-72c7ee20e974" class="OWAAutoLink" data-auth="NotApplicable">https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a><br>
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!</div>
</body>
</html>