标签: end-of-life

我目前正在管理一个AngularJS开发项目.有人说我们需要从目前的1.2中至少迁移到AngularJS 1.5.我要求移动的一个要求是我必须提供1.5的支持结束的证据,但在角度站点和多个谷歌搜索后数小时后找不到支持信息的任何结尾.

是否有关于何时不再为Angular v1.x开发安全补丁和错误修复的官方评论？

在我工作的公司,我们有一个成功的软件产品表现不错,但现在已经过时且不可维护.我想解释一下,为了生存,你需要创新并用新产品替换这个产品.我正在寻找一些公司的好例子,这些公司犯了我们即将犯下的错误 - 依靠一个成功的产品方式超过它的正常生命,所以我可以在做出论证时用它作为例证.

这些产品不一定是软件,象征性的案例,很好地说明了这种情况,但产品不是软件也受到赞赏.

Android 版本是否有官方生命周期来说明每月哪些版本会收到安全补丁？

如果您查看最新的安全公告，您会发现 8.0 仍在接收补丁，但我想知道这种情况会持续多久。

这篇维基百科文章中的表格列出了 9.0 之前的所有版本不受支持，但这些行的引用只是链接到该版本 Android 的营销网站，我在那里找不到任何有关安全补丁的信息。

注意：据我所知，实际获得设备更新取决于制造商和运营商，并且不能保证与 Google/AOSP 匹配，我只是在寻找 Google/AOSP 的官方消息，说明他们何时停止向给定的设备推送安全公告Android 版本或仍受支持的版本列表，而不仅仅是查看最新公告上的版本。

我们有一个使用传统ASP和VB6/COM +的遗留系统,并计划迁移到.NET堆栈.

我们正在尝试制定迁移计划,一个关键的驱动点是"我们的旧东西什么时候停止工作？".

对于VB6/COM +,微软已经声明它没有计划在Windows 7之后的Windows版本中包含VB6运行时(是的,我知道这可以解释).

我还没有找到类似的经典ASP声明.我见过人们参考了Windows 2008 Server R2的Microsoft生命周期计划(这是2018年的某个时间)并推断:

(a)由于经典ASP在Win2008R2上运行,
(b) Win2008R2在2018年之前是好的,然后
(c)经典ASP在2018年之前是好的.

我不确定是否购买,特别是因为我们有合同义务在它们出来后的几个月内支持新版本的Windows xx,因此保留Win2008R2作为解决方案不是一种选择.

任何人都可以向我指出微软关于经典ASP生命终结的事情吗？

我知道libspotify将不再获得任何支持,并被webapis取代.我没有任何问题,因为libspotify可用性很糟糕,并且有很多不修复的bug以及许多缺少的功能.但是,无法获取任何流URL或具有用于流解码的小型库.

我们承诺,一个新的小型替代库将很快"提供"近4年,并且部分libspotify已经关闭.除此之外,有一段时间,有一个说明,libspotify将在2017年关闭.

我并不关心Web API提供的任何内容,它几乎在任何方面都明显优于libspotify.我所关心的只是一个简单的播放器API,我可以在其中输入Spotify轨道URI并获取原始PCM帧(可以输出到扬声器,流式传输到不支持的设备等).

你已经在android SDK里面有这种类型的库,它提供了我们所需要的一切.不为非Android平台(win32,Linux,mac)提供标准c库的原因是什么？

或者提供一种获取RTMP或HTTP流URL的方法,就像它在Spotify网络播放器中完成的方式一样,这会更好.

我非常喜欢Spotify,希望能够继续开发使用它的应用程序.

随着Sun被Oracle接管,Oracle可以说可以获得对Glassfish的控制权.

我确实理解Glassfish是社区驱动的,但目前大部分贡献来自Sun.

它是一款出色的App Server,非常适合许多对成本敏感的客户.但是,如果甲骨文决定从我们的脚下拉下地毯,我们可能会对我们的客户造成严重的麻烦.

对于寿命约为5年的解决方案(应用程序),将Glassfish作为应用程序服务器仍然有意义吗？

Rails 2.3的EOL日期是什么？

是否有自动方法来确定或查找图书馆的生命周期结束 (EOL)/支持结束 (EOS) 通知？

这背后的具体背景：

我们的软件使用了大约 50 多个库以及一些平台。我似乎找不到一个自动化的解决方案，它告诉您某个特定的库是否已终止支持。

我遇到的当前解决方案是 Black Duck。我的理解（仅使用 Code Center 后）是 Black Duck 更关注 OSS 治理，不包含专有软件。Black Duck 确实会通知用户有关安全更新和许可证冲突的信息，但据我所知，它不会通知用户 EOL/EOS。

我们目前的解决方法是执行以下操作：

• 列出我们使用的所有库（我们使用 Artifactory 执行此操作）
• 定期检查图书馆网站以获取任何通知
• 然后以某种形式维护它（目前是一个维基页面，这是一场噩梦）

出于术语目的：

一个 jar 或 npm 模块的库

当使用 Vue 作为独立的 SPA 时，在 2023 年 12 月 EOL 后肯定不会发现任何重大“漏洞”。

我使用 Vue 作为一个独立的前端 SPA，带有 Express REST API 后端，几乎所有的“风险”都在后端，所以我想象如果我正确配置了我的前端（使用环境变量）等），Vue 2.7 到 2030 年仍应该可以投入生产吗？是否应该使用到 2030 年则是另一个问题。

我出于商业合法和个人原因不升级到 Vue 3.x。大多数人升级是因为生态系统遵循 Vue 3，我只依赖 Vue-CLI，而我的 Vue 2 代码库太大，如果没有安全动机，无法重构。

这是一个困难的问题，因为大多数软件无法用作独立的前端，因此我在互联网上收集到的关于此类框架的安全漏洞的证据并不多，停产后。

我最近发现 GitHub 不再维护 Atom 编辑器。无法再安装这些软件包，因为该服务已被关闭。

我喜欢 Atom 编辑器，但不想使用 Visual Studio Code，就像 GitHub（即 Microsoft）建议的那样。

是否有任何合理且有效的分叉可以继续在该编辑器上工作？