I've made the mistake to write a complex project in Free Pascal. As far as I can tell pretty much every release of Lazarus is breaking something.
And surprisingly often those breaks are major (like e.g. broken multi-threading, broken-strings, ...).
For me the whole thing looks more like a playground for hobbyists and is not really useful for anything productive.
There's not much continuity in the language. And for the devs something like 95% compatibility seems to be good enough.
For small projects it might be ok to use, but you better keep your snapshot of the compiler locked in a safe place.
On the other hand: If you're young and want to make history as the guy who replaced all those begin/end in pascal with smileys: This project might be your chance...
I work with a multi-mloc application in fpc. We have migrated the code over many compiler versions with hardly any issues at all.
With every update they post a list of things breaks compatibility, and if you are affected, the refactoring tools are almost always enough.
We had two tries at a full recompile migrating from 2.6.something to 3.0.2, and passed all tests within 13 hours of starting the process. (some of the larger stuff were however already fixed since we keep a close eye on the development).
Your project was probably doing something wrong or weird since the Lazarus and Free Pascal developers have gone to great lengths to avoid breaking backwards compatibility - i have code from 10 years ago that compiles almost without changes. The only change that i have to do is when i abused strings as byte buffers that wouldn't work in Free Pascal 3.0. However that was something the FPC developers said for years and they made several release candidates so that people can report back issues. Even then the change was simply replacing all uses of `string` with `rawbytestring`.
The only backwards compatibility breaking they do is when they are fixing compiler bugs that shouldn't be used anyway. For example at some point it was possible to take the address of a property getter and this usually worked, but not always. They changed that to be illegal (according to the language reference it was illegal anyway) so any code that relied on that would need to change (a simple change would be to make a new property or function that gave back the address of the private reference and mark it as inline so that you wont get any performance penalty).
Personally i am very anal about backwards compatibility and i have abandoned tons of libraries (SDL, GTK, Qt, etc) because of that. In my experience Free Pascal, LCL and Lazarus are among the most stable frameworks to the point that they prefer to keep unnecessary things around for years just in case someone is still using them or introduce unnecessary options for the framework to change behavior in case someone is still relying on the old one (this is why for example you get a `RequireDerivedFormResource:=True;` line in new projects, older projects wont have this line which affects the behavior of how forms are created).
Obviously i don't know what your project was doing but you don't really provide any description (both of the issues you mentioned i haven't encountered), so i put my counter-experience here since i wouldn't like people to get the impression that Lazarus doesn't care about backwards compatibility. For me it is a prime example of a very complex project doing backwards compatibility right (hell, the Lazarus IDE itself can even be compiled with Free Pascal compilers that are years old just in case someone might for whatever reason - like the few cases mentioned above, or use FPC from some Linux distribution that only has old versions - be stuck with them). Things that break backwards compatibility are considered important bugs and are fixed - sometimes even at the cost of getting things "right".
Broken multi-threading, broken string, ...
Care to elaborate? UTF8 move perhaps? Which native compiler/RAD got UTF8 for free? Virtually every C/C++ project was "broken" in that respect at some point or even now.
I use both Lazarus & FPC from trunk (in between releases) and even then backward compatibility is of top priority to FPC devs.
I have had best success by using the (very stable) version provided in (X)ubuntu LTS, which I'm always staying with, so I'd say it is about finding a good strategy for version selection.
I like your comment. It highlights what misses from so many discussion about languages/tools down here. Being expressive, powerful, compiled, interpreted doesn't matter much if long term stability, reliability, backward compatibility are not a top goal for the devs.
The same was for Delphi, but no one complained in such way. Your sources were to update accordingly, or you simply remained on previous version, which was not a bad thing, because it is your app, it was working yesterday, why would it break tomorrow?
For new projects you took new libraries.
Personally, I don't like the modern idea of autoupdated anything. Once program is tested and deployed, only cherry-picked (or backported) security updates must be applied.
For me the whole thing looks more like a playground for hobbyists and is not really useful for anything productive. There's not much continuity in the language. And for the devs something like 95% compatibility seems to be good enough.
For small projects it might be ok to use, but you better keep your snapshot of the compiler locked in a safe place.
On the other hand: If you're young and want to make history as the guy who replaced all those begin/end in pascal with smileys: This project might be your chance...