当新版本的框架或语言出现时（例如.NET 3.5，SQL2008），人们采取何种方法来采用/升级？何时升级到语言或框架的新版本？
通常情况下，开发者会尽快说（他们希望在他们的简历和管理角度给他们他们想要的东西提供动力），但商业上往往没有激励（很少有客户要求最新版本）和从成本的角度来看（重新测试，培训）往往是一种阻碍。
我特别想的“正在进行的”系统和项目（如软件公司）的存在和发展多年来这里走的是“新项目使用新技术”的方法是行不通的。
是否由特定需求驱动（需要使用新功能，潜在客户或现有客户需要支持），他们是否正式评估（在哪种情况下是什么标准）还是升级为常规问题（在哪种情况下 - 前缘与出血边缘）？
人们是否认为不可正对某事的最新版本，应考虑技术债务，因此管理？
或者是“如果不破不修”的有效方法？
请阅读Technical Debt。这是一个简单的成本效益决定。
“如果没有破产就不能解决问题”是一种常见的管理政策，即“明天的美元不像今天这么值钱，所以不要为将来的改善做计划。”最终技术性债务累积到产品不能再一瘸一拐的地步。
最常见的突破点是当某些基础设施不再受支持时。届时，增量更改是不可能的。
从头开始重塑一个新的资本投资。修复现有代码是一项费用。这些账户迫使管理层做出技术上疯狂的决定。
在开源软件的情况下，需要仔细的技术管理，因为有一个从甲骨文/ Sun没有官方的“支持日落”公告。不好的技术管理当然会导致技术破产。
当升级（更多的功能，或者您需要一个bug修正）的收益大于所涉及的风险/成本（新的问题，打破现有的代码）。
我们看看支持生命周期成本。旧版本支持多久，费用是多少？与大型机环境相比，像Windows和Java这样的平台往往移动速度很快，而在这些平台上开展业务的部分成本是执行定期升级。在理性的世界里，那就是！
新版本可以有我们需要的杀手锏 - 但这是在企业发展中罕见。新版本的主要积极卖点（相对于过期支持等负面消息）往往是更大的开发效率，这很难衡量。与此相反，正如您所表明的那样，必须考虑重新培训的成本，不仅仅是最初的开发人员，而且关键还在于维护。在每次升级过程中，一些应用程序往往被抛在后面，对于退休来说过于关键，而且升级太昂贵/脆弱。随着时间的推移，您必须支持的平台和版本的号码会增加整体技术债务（无论其年龄）。
升级到新版本（您注意到）的另一个标准是吸引和留住员工的能力。随着目前的经济阶段，这是第二次小提琴，但仍然不能完全忽视。你希望至少有一个充满热情和知识的开发人员的调料。
我觉得这个要命的问题是你的应用程序是否能长期生存，如果你从来没有升级平台/语言版本。如果你认为它不行，那么你可以尽早升级而不是稍后升级，因为它只会变得更难。
想想多久你的应用程序应大力发展，直到你需要一个完整的重写。如果您从未打算重写它，我会不断升级。考虑一下，如果你正在使用过时的技术，找到最好的开发人员将会变得多么困难。考虑一下新的框架/语言功能如何加速您的开发过程，从而避免短期的痛苦。
当您开发基于Microsoft平台，就像一个Windows窗体应用程序的Windows或Web应用程序ASP.NET为Windows Server，漂亮的时间迁移是OS.For例如每两个主要版本，如果你的应用程序已经为Windows 2000开发，你应该迁移到Vista，尽管XP可以被忽略。同样，如果它被设计为XP SP2，您可以放心地忽略Vista和目标赢7.通常微软从来没有休息（或不易破裂）增量操作系统的更新。所以在今天的操作系统上运行的应用程序肯定会运行在下一个。但从来没有跟随它。 （如果它运行如何M $赚钱???）
来源：自筹...... Windows 8开发者超过5年）
当你真的需要。 .NET 1.0很糟糕，1.1是一个不错的升级，但VS2003的Web开发并不那么流畅。用VS2005和.NET 2.0改进了一些东西 - 我发现还有很多开发人员和公司都坚持使用.NET 2.0。以前的版本是如此新鲜，2.0版本是成熟的技术。所以，如果你对1.1感到满意，为什么要升级？如果你现在开心2.0，为什么升级到3.5或4.0？
我正在尽快升级阵营（虽然我可能会在一个新版本发布后等待一个月，以防未被发现的问题）。有你需要考虑几件事情：
1.安全发布的
许多谁告诉我，如果不破不解决它的人也都是同样的人谁也当安全补丁发布时关闭他们的两只眼睛。考虑Equifax。
对我来说，至少在安全支持的框架版本上是一种道德责任。我们有责任保护他们的数据。
2.吸引&留人
有很多讲的关于如何使用的编程语言或框架并不重要。但根据我的经验，对于Web应用程序而言，最简洁的代码和设计通常是由那些对编程语言充满热情的人撰写的，因为他们具有专业知识，所以他们使用的编程语言是&。
如果你坚持一个非常旧的版本，这些人不可能长期呆在家里或加入你的公司。请考虑你的开发者的幸福。通过新版本
提供
3较新的，更简单的方法很多时候一个框架的新版本使过去坚硬的东西要容易得多。如果我们不升级，我们错过了很好的新软件包/功能，并且我们以旧的令人沮丧的方式编写我们的代码，知道有一种更简单的方法来实现相同的功能。而当升级时，我们可能最终不得不再次改变新的方式。那么为什么不升级和使用新的更好的方式，浪费更少的时间呢？
那么基于此，如果没有特定需求，您可能会永远停留在旧版本上？ – 2009-05-05 11:03:45
绝对是的。 – PaulJWilliams 2009-05-05 11:08:30