[superq]

Backwards compatibility is there for a reason.

So many things could be broken if we didn't insist on backwards compatibility with ancient systems. Virtually everything, for just one example.

Can you imagine if we didn't bother with backwards compatibility for servers? Or even just your desktop - you try to boot one day and find that your desktop doesn't boot because we dropped compatibility with MBR systems and only support UEFI, or that you choose ext4 for your filesystem, but the kernel only supports superqFS version 2023.07 ...

or that SSH backup script that has been working fine for 20 years suddenly, silently, stops working, and then your critical production systems die.

Or how about your favorite photo software decided to just change all of its keybindings, or stopped loading your photos -- from last year!

[brazzledazzle]

>suddenly, silently, stops working

Not to detract from your overall point but for anyone out there wondering about a way to handle this in general: your job should update or annotate something (a file, a table, a bucket, etc.) upon success. Then you use a "dead man's switch"-style check/monitor that alerts if the job hasn't updated its proof of life, so to speak.

[superq]

but then who's watching the watcher.. ;)

[sim-]

It'd be nice if they didn't break, but for example, since around OpenSSH 7.7, the order argument parsing changed from last wins to first wins. This change broke all of my aliases where I used to be able to have an alias sr="ssh -l root" and override the user with something such as "sr foo@host".

Last wins is how most other UNIX tools work, since it's the laziest approach (parse from first to last and just overwrite any old value). But I guess somebody tried to be explicit with the order of everything from the configuration file including the command line, and now this happened.

I really wish this would be reverted, but now it's probably been so long that it would break things for people again.

[hfkwer]

Your examples aren't relevant at all and full of hyperbole. Are you replying to what I wrote or showing off your oratory skills to the peanuts gallery?

SSH is a protocol. Just have the client negotiate the version of the protocol when establishing a connection. Use the old protocol by default, write new scripts with a flag requiring the new protocol from the server. Boom. You maintain backwards compatibility with ancient systems, but you don't force old mistakes upon current day users.

[ndsipa_pomu]

> SSH is a protocol. Just have the client negotiate the version of the protocol when establishing a connection. Use the old protocol by default, write new scripts with a flag requiring the new protocol from the server. Boom. You maintain backwards compatibility with ancient systems, but you don't force old mistakes upon current day users.

The problem isn't so much the protocol (SSH already does the client/server protocol negotiation), but the command line interface to the SSH tool. Changing the interface can stop older scripts from working in the same manner, so either you have to add completely new options to the CLI so that the older usage still works, or you have a renamed version of the tool (e.g. nussh) that won't need to worry about backwards compatibility.

[hfkwer]

>Use the old protocol by default, write new scripts with a flag requiring the new protocol from the server.

Next time, read the whole comment before replying.

[CrampusDestrus]

Not a problem for free software, just update the old code if stuff breaks ;)

[mcny]

> Not a problem for free software, just update the old code if stuff breaks ;)

I know one qa team at Google had the slogan "if it isn't broken, you aren't working hard enough" but they are the qa team. It is their job to find defects before anyone else.

It is not our job as developers to create defects for no reason.

[superq]

If you can even still get the updates on the backwards-incompatible package manager. (as anyone who's ever maintained an Arch system has probably run into, and even Red Hat used to run into this problem way back in the day.)

[CrampusDestrus]

well, that's another problem. there is a difference between what the developers see and what the users see.

the developers should have access to the updated API/ABI code and maybe some migration documentation in order to update the program. the user should have a clear migration process to avoid data loss or corruption.

in this case, the package manager's core functionality should not depend upon any other packages. this way you can just store all the previous versions of the program and provide an upgrade path. sure, it will take a bit if you're doing a big upgrade, but that's tour fault for not keeping stuff updated