3 ms·
The exact opposite is more likely true, depending on the nature of the change. A new utility has no current usage so there are no in-the-wild backwards compatib
by thwarted 5y ago
The exact opposite is more likely true, depending on the nature of the change. A new utility has no current usage so there are no in-the-wild backwards compatibility concerns. The system python on redhat based distros was stuck at 2 for a long time because some of the sysadmin utilities relied on it and all those deps needs to be vetted or converted to either a newer python version or their own shipped version of the runtime that didn't use the general purpose python install.
- _ea1k 5y agoThere's a big difference between a bump to the latest curl version and a jump between two major versions of a language runtime. The Python 2->3 transition took years and many distros kept both versions. Most dependencies get updated much more quickly. It wouldn't even shock me if this change got picked up mid-cycle.
- bonkabonka 5y agoUnhappily RedHat won't. Heck, RedHat has gone well out of their way to backport updated TLS handshakes (1.2 at least) to their 2013 version (7.29.0) of curl.
- _ea1k 5y agoI'm assuming that you mean for RHEL? That's a little bit of a special case.
- jedberg 5y agoPython is a huge outlier in this case. Very rarely do you have a default tool that can't be upgraded, and this case was only because Python is an interpreted language. Curl is a command line tool. As long as they only add new functionality, there is very little that prevents an upgrade.
- ericbarrett 5y agoThis is only a valid comparison if curl deprecates or moves options, as Python 3 did with language features and standard library functions.