4 ms·
I also think this really shows the disconnect in mentality between the younger developers and the 'older' ones (I quote this because while I am 25 I often find
by snuxoll 11y ago
I also think this really shows the disconnect in mentality between the younger developers and the 'older' ones (I quote this because while I am 25 I often find myself in the latter category).
Software used to be a thing you maintained, if you made a major release you would continue to support the old one for a period until users (in the case of libraries, developers are your users) had a chance to migrate off of it. This meant releasing security updates and bugfixes for the old release in parallel to the new one - or at least making it not impossible for these changes to be backported.
Now everyone wants to be evergreen - you're still using 1.2.x of my library that has glaring security issues that have been fixed in 2.x? Well, better upgrade, because I'm only supporting the newest release.
As someone who has to constantly deal with the headache that is NuGet for their day-job, I absolutely loathe this mentality and the idea that everyone should just use their language package manager. If any of the NuGet packages we use internally has some glaring security issue, I've got 20 applications to update, test and redeploy on a good day if there's no breaking changes - at least if for whatever reason the Fedora packagers can't backport a security fix for a python package I depend on it's easy enough to push a new version out in my local yum repository and have it automatically fixed for every application that uses it.
- 3pt14159 11y agoIt's gotten too onerous to support old software. There used to be one Linux, one BSD, and a couple of Windows / DOS. Mac was probably around too, I just never interacted with it in the 90s / early 2000s. Backporting security fixes and replicating interconnected bugs across all the combinations of setups is impossible. Just getting the latest version fixed in all is onerous. Keep current is my philosophy. It's why I like the Ruby community, the global namespace makes it impossible for libraries to stay behind too long.
- dozzie 11y ago> There used to be one Linux, one BSD, and a couple of Windows / DOS. Mac was probably around too And AIX of several releases. And HP/UX. And SGI Irix. And Solaris + SunOS, again, of several releases (mostly backward compatible, though). Don't say it was easier then than it is today, barring the young guns constantly breaking their new Node.js packages and Ruby gems.
- 3pt14159 11y agoYeah but everything is online right now and we're moving more and more data that _must_ be secured. Back then you really only cared about a couple of platforms - nobody cared if you could hack some random dudes garage or phone.
- snuxoll 11y agoEven then, who cares. Software developers didn't have to explicitly support BSD, if there was a BSD user who cared enough they'd work on getting your package in the ports tree. If there was a Debian or Red Hat user that cared enough they'd make a .deb or .rpm. None of this has changed, what HAS changed is library and application developers deciding to say "screw people using existing releases, I'm only putting bugfixes and security updates in the newest release so anyone still using 1.x and caring about stability can sod off". I package software I care about, but libraries in particular are notorious for not maintaining any semblance of ABI or API compatibility even between minor releases these days. It's increasingly difficult to support this when I have to rebuild or update multiple applications that depend on a library because they decided to make huge breaking changes in a point release or they won't provide any bugfixes for the major release I'm still on.
- snuxoll 11y agoNobody is asking you to test your software on a million different platforms, just don't abandon your 1.x users the moment you release 2.x. I am not talking about explicitly supporting XYZ distribution, because package maintainers and software developers are two different groups of people.