This is the mail archive of the
mailing list for the Cygwin project.
Best practices in IT systems management [was RE: Is there a way to install old version cygwin?]
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: <cygwin at cygwin dot com>
- Date: Tue, 10 Oct 2006 19:40:03 +0100
- Subject: Best practices in IT systems management [was RE: Is there a way to install old version cygwin?]
[ Linda, please don't take this post personally; it isn't specifically directed at you or anyone else, it's just that I've been meaning to write a few paragraphs to explain these concepts for some time now, and chosen to piggy-back on your thread because it's equally as good an example as any other. ]
On 10 October 2006 19:11, Linda Walsh wrote:
> Eric Blake wrote:
>> For example, it may just be a matter of figuring out which scripts
>> have DOS line endings but reside on binary mounts.
> Having this issue surprise me, recently, on an upgrade of
> What was changed recently?
You upgraded bash!
Or in other words, to be explicit, "Read the (fine) release announcement for full details". Which is generally a good thing to do /before/ upgrading rather than later.
As far as I'm aware, it's only huuuuuuge projects like gcc and mozilla that have "release branches", where you can be guaranteed that an incremental (sub-)minor version upgrade will contain no new features, no backward compatibility breaks, and nothing but bug fixes.
For everything else (and in particular, bash and make), you *must* expect there to be changes between release versions /as well as/ bugfixes, and you should not automatically and unthinkingly upgrade from one version to another. Read the NEWS file, read the ANNOUNCEments, and consider whether or not you /want/ the changes that the new version brings.
Don't upgrade just because you want the newest, shiniest version; if you have a stable system, that is working for the jobs you want it to do, you should really consider very hard /why/ you would want to change any part of it. Unless you have actually run into a bug in /your/ usage, and that particular bug is fixed in the upgrade, you are on what is technically known as "a hiding to nothing" most times.
As a datapoint, it's interesting to note that the version incremental backward-incompatibilities in automake/autoconf/aclocal are orders of magnitude huger than anything caused by having to d2u the occasional script or specify a /cygdrive/c path instead of a dos path. Try and run automake 1.9 against a bunch of *.am files you wrote for automake 1.4, the amount of errors and incompatibilities would make your brain explode! Yet nobody complains about these changes, and everyone just accepts that the source files will only work for the correct version of auto-whatever. Anyone using these tools knows not to go randomly upgrading them unless they're prepared to port whatever depends on them, and the same goes for every other tool, albeit usually in less drastic fashion.
This all goes double or triple for production systems that are doing important daily work. For example, Microsoft don't just upgrade all their hotmail servers to the latest version of Apache every time it comes out[*], they keep the mission-vital systems untouched until they've verified a potential alteration will bring benefits and not cause problems.
This is all standard procedure and best practice; none of it should be terribly surprising.
[*] - Well, maybe they finally have transitioned hotmail onto IIS now, I don't actually know, but for many years hotmail ran on apache servers. I'll still bet you they don't just upgrade them all to the latest version of IIS every time there's a release without making sure there's a good business case to justify the migration and a thorough testing of the proposed new release.
Can't think of a witty .sigline today....
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html