Technical considerations in dropping support for old compiler versions?

Question

I work on a project that's distributed for free in both source and binary form, since many of our users need to compile it specifically for their system. The necessitates a degree of consideration in maintaining backwards compatibility with older host systems, and primarily their compilers.

Some of the cruftiest of these, such as GCC 3.2 (2003!), ICC 9, MSVC (almost abandonware, not C++!) and Sun's compiler (in some old version that we still care about), lack support for language features that would make development much easier. There are definitely also cases where enabling users to stick with these compilers costs them a lot of performance, which runs counter to the goals of what we're providing.

So, at what point do we say enough is enough? I can see several arguments for ceasing to support a particular compiler:

• Poor performance of generated code (relative to newer versions, asked about here)
• Lack of support of language features
• Poor availability on development systems (more for the proprietary than GCC, but there are sysadmin issues with getting old GCC, too)
• Possibility of unfixed bugs (we've isolated ICEs in ICC and xlC, what else might be lurking?)

I'm sure I've missed some others, and I'm not sure how to weight them. So, what arguments have I missed? What other technical considerations come into play?

Note: This question was previously more broadly phrased, leading many respondents to point out that the decision-making is fundamentally a business process, not an engineering process. I'm aware of the 'business' considerations, but that's not what I'm looking for more of here. I want to hear experiences from people who've had to support older compilers, or made the choice to drop them, and how that's affected their development.

Answer 1

Your question is conceptually the same as web developers who want to know when they should stop supporting Internet Explorer 6. The answer is that you have to do research.

1. How many people use the older compilers?
2. How many use the newer ones?
3. How many will be willing to upgrade?
4. How many users will you lose? (This can be calculated from the answers to 1, 2, and 3).
5. How much time and work would it save you to drop support for the older compilers?

Basically your decision comes down to comparing the answers to 4 and 5. It seems like this is an open source project from your description, but if it's a business, you can compare it numerically (if money lost is less than money saved, drop support). If it's not a business, it's a bit more complicated, as you have to guess the human cost, which can be a bit tricky.

Answer 2

Well, the usual way to go about this is first to ask. I assume you have a mailing list of a webpage or something to facilitate that. So ask: Who will be affected and how hard would it be to upgrade if we drop support for any of these compilers. After doing so, you'll get an idea if it is worth the hassle to keep supporting these compilers.

It might also be kind to flag the last working version for each compiler-version you decide to drop support for, so that anyone who really cares can keep on using that old version.

Answer 3

I don't think it is particularly anything to do the efficacy of old compiler tech. It's a business decision, and really boils down whether you want to keep your customers or lose them. Customers don't deal in tech, they deal in business and business decisions.

Ideally you want to define some kind of metric that constructed on how many customers you have, against the different compiler versions they are used, against the cost of maintaining particular versions of each compiler type.

Fundamentally, you really need to be careful when and how your going to tell your customer base that your going to retire part of your product set. How you tell them as well. Just drop it in their lap. Plan it.

You need a internal approved controlled policy, and start rolling it out, perhaps telling them at user group meetings, and then ensure you have decent length of time (2 years is good, allow the customer to complete current implementations (1 years) plus some slack, before you start implementing in, and have a support framework in place, to help customer migrate in time.

How you plan this will define how your customers react. A few years go, I was working in software house, which sold a really complex high end product for controlling electricity networks. The product sell £2m for the complete package, and each customer signed for a 25 year support contract. Somehow we decided to rationalise hardware. We were offering it on AIX, Solaris, Tru64 and HPUX. But for reason we decided to rationalise it on AIX, which I think we had a deal. Anyway, one of the customers which was a Solaris shop got really upset about this, and then for the next 4 years we never heard a word from them. No phone calls, patched, on site audits. Nothing.

The reason we decided to change it, as we did a 6 sigma project, and it indicated we would save about £19m a year, buy rationalising the infrastructure to AIX and NT. But in the end up, we ended up fxxking off one of our primary customers, virtually destroying our user group community.

The decision was made hastily, and it backfired. So I think your best idea is to plan it.