On Friday, 29 October 2021 at 20:39:56 UTC, Adam D Ruppe wrote:
> On Friday, 29 October 2021 at 19:21:43 UTC, harakim wrote:
> I dread coming back to my projects and having to spend time to get them to recompile.
Do you have a recollection of why, specifically they would fail to compile when you get back to them? Language changes? Std lib changes? Third party libs? And how difficult it was to update them?
"breakage" isn't really a binary yes/no thing. Some are worse than others. One example I did in my minigui was misspell a word. I made that a deprecated alias with the message saying "it was misspelled, use THIS instead".
Now, worth noting, that isn't exactly breakage, since you can just ignore the message. I've left it like that for years now; it doesn't really hurt anything. (My own libs' policy is actually pretty strict - I almost never break anything and maintain compatibility with both old and new compilers, and with simple build systems; my "no breakage" policy even includes the specific compile command line. And when I do break something, I make it as easy as I can think of to make migration quick and painless.)
But still that's an example of a partial break that is easy to deal with. Should be able to update it in a matter of minutes.
And compatibility shims are easy: the deprecated alias is something you could too in your code. Doesn't have to be in mine. So you can choose your own compiler as well.
This is how I'd like the stdlib to be too. Where changes are needed, you make it easy. Where they're not needed, you can leave it alone.
Phobos needs some changes right now. That doesn't mean you have to delete the current code, but you also can't leave it alone out of fear of what might happen.
> Why doesn't it compile?
I'd like to know that too. Is it really the language's fault? And why couldn't you keep using the same version you had before?
You have a point. I believe this was the compilation issue I had last which appeared to be a backwards-compatibility issue in the std lib:
auto sekunden = to!("seconds", double)(dauer);
return cast(long)floor(sekunden * 18);
It used to compile and now it doesn't. It's not a big deal. I know I have had more like this in the past but I have not kept track over the years. The only time I felt overwhelmed was when I switched from Tango + version 1 to Phobos + version 2, which is reasonable.
The point you got at was that it's mostly third party libraries I have an issue with. That is true. I had to re-download the DerelictSDL source and I did not know which version since I hadn't saved it on the flash drive with my project. When I got it, it wouldn't compile. I upgraded compilers because it used newer library functions (and made a few other fixes), but it didn't draw anything after I did that. I wasn't sure why so when I saw this message:
> ###THIS PROJECT IS NO LONGER MAINTAINED!
It doesn't compile with the latest version of DMD and I will not be updating it.
I ended up moving to a new library, bindbc.
This is just a description of the last time I pulled out an old project. There was:
- An instance of a library function being added in a minor version, which caused me to have to upgrade to use the current version of the library. Even though I was previously using the same major version, it would not compile.
- An instance of a library function call breaking with only minor version upgrades.
Problem #1 would fine if it weren't for problem #2
My argument is that we should:
-
Signify breaking changes in the version number. Code using a library with version x.a should compile using any version of the library x.b, where b>=a.
-
Breaking changes should be limited to infrequent releases. Multiple breaking changes should build up and get released at the same time with an upgrade guide of some sort.
Maybe I'm just not having the correct perspective or even understanding when it comes to framework and language versioning. I just know that I have to worry about these things in D, but not in other languages.
Permalink
Reply
