Question about dcu binary compatibility - has there been any cases in any versions of delphi, where an update has intentionally been binary incompatible? Ie to the point where third party libraries needed to be recompiled for the update?
Question about dcu binary compatibility - has there been any cases in any versions of delphi, where an update has intentionally been binary incompatible? Ie to the point where third party libraries needed to be recompiled for the update?
Intentionally? Inside the same major release? Not that I am aware off. According to David Millington this is something to avoid at all cost.
ReplyDeleteThis doesn't mean that some libraries have to be adjusted because they make use of some undocumented internal behavior that has changed with the update.
Uwe Raabe Thanks, I'm not aware of any instances, but don't trust my memory to be certain.
ReplyDeleteSome 10.2.1 builds was binary incompatible (not all units)
ReplyDeleteAlexander Sviridenkov but those were fixed with an update, ie they were not intentional right?
ReplyDeleteThere was an unintentional case not long ago where they had changed the interface of a unit in an update. Don't remember the exact unit or version, sorry.
ReplyDeleteVincent Parrett yes, but some people still use these builds.
ReplyDeleteYes, we always try to have version updates for a major release compatible (eg, 10.2.0, to 10.2.1, to 10.2.2, to 10.2.3.) We'd then introduce interface changes in 10.3 as a new major version. This means all components and code built with one of those versions can link and run with code from another. It does limit us slightly for what features and bug fixes we can introduce, often having to leave some for a major version when we can freely change interfaces, but we have very strong customer feedback that having major versions and thus upgrades too often is not desirable.
ReplyDeleteA caveat is that in C++Builder we break release-to-release compatibility more freely. This is a judgement call allowing us to make more changes, and C++ developers are used to rebuilding all code for a new release in any and every environment.
We did unintentionally have an incompatibility in 10.2.2, and we re-released a new build of that version. From memory, we also contacted all affected customers, ie those who downloaded. I would not place much significance on the possibility of people still using the affected build, and if you encounter errors it's easy to check: the fixed one is build 2004. http://blog.marcocantu.com/blog/2017-december-delphi-10-2-2.html
Oop, misinterpreted the question. Delphi 2007 was binary compatible to Delphi 2006. That extended even to packages if I remember correctly.
ReplyDeleteVincent Parrett - this is a rare occurrence. I think I can say that they try very hard not too. Sometimes, , it is a very tall order to maintain compatibility. Back in my day, we had only compiler (and platform) to worry about.With all the new compilers Embarcadero has added, I salute them for the job they have done.
ReplyDeleteI a unsure if "intentionally", is a good way to describe. Yes, to make a fix, this is sometime "necessary", however, I do not believe there is anything nefarious going on in the process, as an incompatibly also burdens 3rd party partners (and sometimes users).
Thanks for the input all. Just to be clear, I'm not experiencing any issues, just wanted to understand the environment, the context being compatibility of dcu's with various updates. ie, if I'm targeting 10.2, did I need to also build for 10.2.1 etc.
ReplyDeleteI'd recommend building with the latest 10.2.x, ie 10.2.3. The majority of 10.2.x customers will be using it, and it should be compatible for people on older point releases.
ReplyDeleteIf I remember the issue with the unintentional breaking change in 10.2.2 was that some implementation of a generic method (TArray.Sort) was changed, but due to the way generics are implemented (materializing as code on the caller side) this caused F2051.
ReplyDelete