> From: "Towle, Jonathan J." <[email protected]> > To: "[email protected]" <[email protected]> > Cc: > Date: Fri, 31 May 2013 15:12:40 +0000 > Subject: [Bug-wget] Compatibility > We are running various versions of wget on our servers. > > On the server we need to use, we are running the very old version 1.9.1. > We could upgrade either to 1.11.4, which we have on most of our servers, or > the latest version. > > Our operate team is afraid to upgrade because existing production jobs are > running 1.9.1. I assured them that it is almost certain that the newer > versions are backwards-compatible, and nothing will stop working. > > Can someone confirm that all these versions are backwards-compatible?
As Giuseppe says, we've tried to be careful to retain backwards compatibility wherever possible. Sometimes compatibility is broken inadvertently (in which case we usually try to restore it); sometimes option combinations that never worked the way the users apparently thought they would, were made errors, and sometimes compatibility was broken for security considerations (such as with --trust-server-names, which is a significant compatibility change). Another example of a significant change is that Wget no longer automatically sends insecure, HTTP Basic authentication credentials with its first request, when a password is provided. It now waits for an authentication challenge, as per the RFCs; but this breaks certain usage patterns, and there's an option to restore the old functionality (--auth-no-challenge). Sometimes even features that didn't exist before, that cause wget to do more than it used to, can cause unexpected results for people who were used to older wgets. My advice is, if you wish to migrate to a newere wget, then you should do it with care. Perhaps have both installed to the same system (perhaps by building one of them by source and installing to a new location, or unpacking RPMs with cpio --extract or .debs with dpkg -x, to other than root. Especially with .debs, that's not a good recommendation in general, especially when a package is expected to start services upon installation, but in wget's case it's unlikely to be a problem. Of course, unpacking archives doesn't ensure that any linked dependencies are installed, and modern wget has more of those than 1.9.x did, so make sure it has what's needed (and try running the newly unpacked wget to make sure it runs). Then you can have a symlink or something that you can swap between them. Try the new wget for a while, and if it makes people scream for any reason, swap back until you can figure out what happened (and let us know, so we can fix it if it's a bug!). Good luck! -mjc
