Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2021-10

Repost: TFieldType declaration change in FPC fixes_3_2 branch

5 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Tony Whyman

/Reposted with correct branch identifier/.

I thought that a fixes branch was only for bug fixes and not for issuing non-backwards compatible changes. However, TFieldType in db.pas now has 6 extra elements.

The result is that IBX no longer compiles with the fixes_3_2 branch. I have also heard the same for zeoslib.

Is the rollout of this patch to fixes_3_2 a mistake, or is there a good reason for rolling out a change that breaks other packages?

Tony Whyman
MWA Software

Reply by email

Michael Van Canneyt
to Tony Whyman
Tony Whyman wrote 11 lines
/Reposted with correct branch identifier/. I thought that a fixes branch was only for bug fixes and not for issuing non-backwards compatible changes. However, TFieldType in db.pas now has 6 extra elements. The result is that IBX no longer compiles with the fixes_3_2 branch. I have also heard the same for zeoslib. Is the rollout of this patch to fixes_3_2 a mistake, or is there a good reason for rolling out a change that breaks other packages?

Delphi compatibility fix:

fcl-db: base: add some of new Delphi field types into enumeration TFieldType (ftOraTimeStamp, ftOraInterval, ftLongWord, ftShortint, ftByte, ftExtended)

Michael.

Reply by email

Tony Whyman
to Michael Van Canneyt

Yes - but is that really a bug fix that justifies a non-backwards compatible change?

Michael Van Canneyt wrote 28 lines
On Sun, 17 Oct 2021, Tony Whyman via fpc-pascal wrote: > /Reposted with correct branch identifier/. > > I thought that a fixes branch was only for bug fixes and not for > issuing non-backwards compatible changes. However, TFieldType in > db.pas now has 6 extra elements. > > The result is that IBX no longer compiles with the fixes_3_2 branch. > I have also heard the same for zeoslib. > > Is the rollout of this patch to fixes_3_2 a mistake, or is there a > good reason for rolling out a change that breaks other packages? Delphi compatibility fix:    fcl-db: base: add some of new Delphi field types into enumeration TFieldType     (ftOraTimeStamp, ftOraInterval, ftLongWord, ftShortint, ftByte, ftExtended) Michael. _______________________________________________ fpc-pascal maillist  -  https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply by email

Michael Van Canneyt
to Tony Whyman
Tony Whyman wrote
Yes - but is that really a bug fix that justifies a non-backwards compatible change?

That's up for debate of course.

Probably it was needed as prerequisite for other bugfixes.

Michael.

Reply by email

LacaK
to Tony Whyman: /Reposted with correct branch identifier/. I thought that a fixes branch was only for bug…
Show quoted text 8 lines
/Reposted with correct branch identifier/. I thought that a fixes branch was only for bug fixes and not for issuing non-backwards compatible changes. However, TFieldType in db.pas now has 6 extra elements. The result is that IBX no longer compiles with the fixes_3_2 branch. I have also heard the same for zeoslib.
As far as I can see ZEOS is full of checks like:
{$IF FPC_FULLVERSION>=30100} ...

So I think that one more check:
{$IF FPC_FULLVERSION>30200}
              {$DEFINE WITH_FTSHORTINT}                 // ftShortInt is supported
              {$DEFINE WITH_FTBYTE}                     // ftByte is supported
              {$DEFINE WITH_FTEXTENDED}                 // ftExtended is supported
              {$DEFINE WITH_FTLONGWORD}                 // ftLongWord is {$ENDIF}
... is not so big problem? (I see there is already in ZEOS such check added ...)

In IBX there you have "DefaultFieldClasses" array which is affected, right?

I agree that it is not ideal situation, but release cycle for major versions of FPC are so long that postpone all these additions to major releases means that users must wait years ...

L.

Reply by email