Thoughts on versioning

harakim harakim at
Sat Oct 30 00:39:21 UTC 2021

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 

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:

>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:
1. 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.
2. 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:
1. 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.

2. 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.

More information about the Digitalmars-d mailing list