Re: [Bug-wget] Compatibility

[Micah Cowan]

> From: "Towle, Jonathan J." <address@hidden>
> To: "address@hidden" <address@hidden>
> 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