On Tue, Jun 22, 2004 at 10:04:14AM -0700, Jim Wilcoxson wrote: > Even if incompatible changes are allowed at major versions, what may > very well happen is that it fractures the community and leaves some > people running old versions longer than they want. We're in this
This has happened extensively with AOLserver in the past, but I think primarily NOT because of broken backwards compatibility, but because there was no attempt at all, sometimes for years at a time, to integrate fixes and patches into the master CVS sources in anything even resembling a timely and reliable fashion. Fortunately, that situation seems to have much improved already, and hopefully will continue to do so. > If a customer has been happily running 3.4 AS for a few years and a > compelling reason comes along for them to upgrade, and the current > version of AS is 6.5, they don't want to run into a big > incompatibility hurdle. If they run into too big of Frankly, there isn't much the AOLserver developers - or ANY external developers - can do about that. As a customer, part of the operatins and maintenance cost of ANY piece of software is upgrading every year or so to the latest and greatest version. If you ignore that maintenance for, say, 5 years running, when you finally do decide to upgrade, no surprise, you are going to have a LOT more work to do, all at once, then if you'd tracked development more closely upgrading a year at time. You'll also have completely abdicated any feedback or input into the software for those 5 years of development, which may further increase your upgrade effort. Make no mistake, CHOOSING to ignore newer versions of software because "what we're using now is good enough" (and I myself have sometimes done so) is a serious operations decision, with both rewards AND risks. And it is fundamentally the customer's responsibility to properly evaluate that decision - no external group of developers can do it for you, nor should they. What developers CAN do, is communicate as clearly, frequently, and consistently as possible where they're currently planning to take the code, when, and why, and be as receptive as possible to fixes and modifications that come from the larger user community. So e.g., ideally, if the AOLserver team finally drive stake through the heart of whatever deprecated legacy support still exists in the core for ns_share say for AOLsrever 5.0, or for 4.2, they'd let you know that well ahead of time, consider ways to provide an ns_share backwards compatibility module and help the (probably very small minority of) users who want that to maintain it, etc. -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
