放弃对旧编译器版本的支持时的技术考虑？
我从事的项目以源代码和二进制形式免费分发，因为我们的许多用户需要专门为他们的系统编译它。需要一定程度地考虑保持与旧主机系统（主要是其编译器）的向后兼容性。
其中一些最粗糙的，例如 GCC 3.2（2003！）、ICC 9、MSVC（几乎是废弃软件，而不是 C++！）和 Sun 的编译器（在我们仍然关心的一些旧版本中），缺乏对语言功能的支持让开发变得更加容易。当然也存在这样的情况：让用户坚持使用这些编译器会降低他们的性能，这与我们提供的目标背道而驰。
那么，什么时候我们才说够了呢？我可以看到停止支持特定编译器的几个论点：
- 生成代码的性能较差（相对于较新的版本，询问此处）
- 缺乏语言功能的支持
- 开发系统的可用性较差（对于专有的比GCC来说更多，但使用旧的GCC也存在系统管理员问题）
- 未修复的可能性bug（我们已经在 ICC 和 xlC 中隔离了 ICE，还有什么可能潜伏着吗？）
我确信我错过了其他一些错误，而且我不知道如何对它们进行加权。那么，我错过了哪些论点？还有哪些其他技术考虑因素发挥作用？
注意：这个问题之前的措辞更为广泛，导致许多受访者指出决策从根本上来说是一个业务流程，而不是一个工程流程。我知道“商业”方面的考虑，但这并不是我在这里寻求的更多内容。我想听听那些不得不支持旧编译器或选择放弃旧编译器的人的经验，以及这对他们的开发有何影响。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您的问题在概念上与 Web 开发人员想要知道何时应该停止支持 Internet Explorer 6 的问题相同。答案是您必须进行研究。
基本上你的决定归结为比较 4 和 5 的答案。从你的描述来看，这似乎是一个开源项目，但如果它是一个企业，你可以在数字上进行比较（如果损失的钱少于节省的钱，则放弃支持） ）。如果不是做生意，那就有点复杂了，因为你必须猜测人力成本，这可能有点棘手。
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.
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.
嗯，解决这个问题的通常方法是首先询问。我假设您有一个网页的邮件列表或其他东西来促进这一点。所以要问：如果我们放弃对这些编译器中的任何一个的支持，谁会受到影响以及升级会有多困难。这样做之后，您就会知道是否值得继续支持这些编译器。
最好为您决定放弃支持的每个编译器版本标记最后一个工作版本，以便真正关心的人可以继续使用该旧版本。
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.
我认为这对于发挥旧编译器技术的功效没有什么特别的作用。这是一个商业决策，归根结底是你想留住客户还是失去他们。客户不涉及技术，他们涉及业务和业务决策。
理想情况下，您希望定义某种基于您的客户数量构建的指标
针对所使用的不同编译器版本，针对以下成本
维护每种编译器类型的特定版本。
从根本上讲，您确实需要小心何时以及如何告诉客户
假设您将淘汰部分产品集。你如何告诉他们也是如此。只是
把它放在他们的腿上。计划一下。
你需要一个内部批准的控制策略，并开始推出它，也许告诉
他们在用户组会议上，然后确保你有足够的时间（2年是
好，允许客户完成当前的实施（1 年）加上一些空闲时间，
在开始实施并建立支持框架之前，以帮助客户
及时迁移。
您的计划将决定您的客户的反应。几年前，我在
软件公司，销售用于控制电力网络的非常复杂的高端产品。该产品整套售价 200 万英镑，每位客户均签收
25 年的支持合同。我们决定以某种方式合理化硬件。我们是
在 AIX、Solaris、Tru64 和 HPUX 上提供它。但出于原因，我们决定将其合理化
在 AIX 上，我认为我们达成了协议。无论如何，其中一位顾客是 Solaris 商店
对此我感到非常沮丧，然后在接下来的四年里我们再也没有听到他们的任何消息。
无需电话、修补、现场审核。没有什么。
我们决定改变它的原因，因为我们做了一个 6 sigma 项目，它表明我们
通过购买合理化 AIX 和 NT 基础设施，每年将节省约 1900 万英镑。但在
最终，我们最终甩掉了我们的一位主要客户，几乎摧毁了我们的用户组社区。
这个决定仓促做出，结果适得其反。所以我认为你最好的想法就是计划它。
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.