资金维护者。
经验支持。
在 HeroDevs，我们多年来一直在帮助团队应对开源软件过时所带来的挑战。通过我们的 "Never-Ending Support (NES) 产品，我们与从初创公司到财富 100 强公司的每个人合作，在官方支持结束后的很长一段时间内，保持遗留代码的安全、稳定和合规性。
我们为无人维护的代码库编写补丁，在无人关注的地方追踪漏洞，并在没有匆忙重写的情况下保持关键系统的安全运行。本基金以这些工作为基础，因此维护者可以继续做他们最擅长的工作，并获得真正的支持。
我们为无人维护的代码库编写补丁，在无人关注的地方追踪漏洞，并在没有匆忙重写的情况下保持关键系统的安全运行。本基金以这些工作为基础，因此维护者可以继续做他们最擅长的工作，并获得真正的支持。
版本发布与版本管理
使用可预测的文档化版本管理（SemVer/PEP 440），通过所有官方渠道公布新版本，并明确标记与 CVE 相关的修复。
沟通与透明度
明确说明哪些版本受支持、已废弃或已到期，并根据项目规模提前通知变更时间。
文件
定义弃用策略，标记弃用版本，指定支持时间表，并说明何时完全删除版本。
支持与报废处理
提供明确的采用/移除时间表，仅将关键修正回传至 LTS，保持非破坏性的弃用，并在更新日志和运行时中提出警告。
流程与层级
保持清晰的问题和安全问题报告流程，定义支持层级（当前、LTS、EOL），并在版本达到 EOL 时鼓励迁移或替代支持解决方案。
选择按标准查看：
版本寿命终止
发布
- 社区会在发生释放时收到通知。
- 应通过所有官方渠道（X/Twitter、GitHub Repo、网站文档等）进行宣传。
- 明确界定新版本发布后的情况。
- 定义主要、次要或补丁发布的影响。
- 当一个新版本发布时，社区就会知道以前版本的最新支持状态。
- 处理 CVE 的版本标识如下
- 向社区通报后向补丁是否缓解了已知漏洞。
版本控制
- 建议项目使用行业标准版本控制（如语义版本控制或 PyPi 软件包的 PEP 440）。
- 如果项目目前没有遵循 SemVer，那么版本结构将是可预测的、直观的，并为社区提供文档记录。
公告通信和清晰度
- 文档清楚地说明了哪些版本是报废版本，哪些是支持版本。
- 宣布发布
- 许多小型项目往往在发布新的主版本时几乎没有任何预兆，并立即放弃对旧主版本的支持；而大型项目往往会提前预测新的发布线，并明确指出对现在的上一发布线的长期支持期。
- 及时发布 EOL 活动公告。
- 需要考虑的基准时限：
- 广泛采用的基础库/框架：12-18 个月
- 中度采用的项目（10k 以上用户）：6-12 个月
- 小型和/或特殊项目：3-6 个月
- 如果适用，现在的上一版本产品线会有一个支持期，以便有时间进行过渡或迁移。
- 需要考虑的基准时限：
- 生命终结事件会发布到项目的官方渠道。
迁移
文件
- 应向用户提供维护者创建和社区创建的迁移指南。
- 迁移指南应该很容易在主网站上找到。
功能变化
- 已废弃的广泛使用的功能已记录在案。
支持
- 在适用情况下，记录了为需要帮助的用户提供的支持选项。
- 第三方服务提供者的引用方式不得违反任何项目或基金会的指导方针。列为提供方的要求应与项目相适应。被列为服务提供者时，应具有作为合格服务提供者的历史和声誉。
支持政策
过程
- 社区有一个报告问题的程序。
- 有一个对所报告问题做出回应的程序。
- 有一个报告违反安全规定行为的程序。
支持层级和文档
- 定义版本支持层级，让社区一目了然。
- 示例 1：
- 当前：全面的安全漏洞和漏洞支持。
- LTS：仅限安全漏洞。
- 生命终结：无修复。
- 示例 2
- 支持
- 生命的终结
- 示例 1：
- 开发人员可以通过文档清楚地了解哪些版本受支持，哪些版本不受支持。
- 对于哪些版本建议开发人员使用（支持），哪些版本打算作为预发布或开发版本，已设定了预期。
鼓励支持
- 在 EOL 事件发生之前，鼓励用户要么进行迁移，要么在目前无法进行迁移的情况下建立一个支持解决方案。
常见问题
获取一些最常见问题的答案。
当然，如果您找不到想要的答案，请随时联系我们。
当然，如果您找不到想要的答案，请随时联系我们。
该计划的目的是什么？
如何获得申请资格？
如何申请？
申请时会发生什么？
资助金额是多少？
该计划有什么要求？我需要做哪些事情才能获得资助？
在完成计划活动时，我会得到支持吗？
我很高兴能为项目的未来工作，但那些不再支持的版本怎么办？基金对这些版本有什么帮助吗？