3GPP 工具链革新提案出炉：诺基亚提议用 Git merge 替代 Git rebase，提升 6G 规范迭代透明度-低调大师

3GPP 工具链革新提案出炉：诺基亚提议用 Git merge 替代 Git rebase，提升 6G 规范迭代透明度

2026-01-21 2

诺基亚近日向 3GPP 提交了一份提案，建议对 3GPP 工具链进行关键升级 —— 将当前用于跨版本变更移植的 Git rebase 操作替换为 Git merge，修改原因是 Git merge 相比 Git rebase，能更透明地展示变更来源，且变更轨迹可追踪，解决当前 rebase 方式在跨版本移植 CR 时的追溯性不足问题，更适配 3GPP 规范迭代中多版本、多 CR 并行的场景。

3GPP 是全球移动通信技术标准制定机构，其核心职能是协调全球通信行业（运营商、设备商、芯片厂商等），制定统一的移动通信技术规范（即 “标准”），确保不同厂商的产品互联互通。

该提案针对 3GPP TR 21.802 规范，适配 FS_6GSpecs 工作项，旨在为 6G 技术规范的高效迭代奠定基础，目前已进入审批阶段。

此次提案的核心设计围绕 Git 仓库结构、版本管理与合并机制展开，针对性解决多版本并行、多 CR（变更请求）协同场景下的管理痛点。在仓库架构上，提案明确为每个技术规范（如 TS 38.300、TS 38.331）单独创建独立仓库，确保变更请求与具体规范精准绑定，分支归属无歧义；同时借助 Gitlab 的分组功能，支持按工作组（WG）或规范系列进行层级化管理，兼顾独立性与分类效率。

版本号演进规则也迎来清晰定义：新一代规范将从 0.1.0 预发布版本起步，经多次迭代至 1.0.0 稳定预发布版，审批通过后升级为正式版本（如 21.0.0），后续通过合并变更请求持续迭代至 21.1.0、21.2.0 等版本。分支管理方面，main分支将专注追踪最新正式版本的动态，采用 “fast-forward 合并” 模式（仅移动分支指针，不创建新提交），从根源上避免合并冲突；新发布分支基于当前版本最新版创建，发布前以 “draft” 为前缀标识，正式发布后生成纯版本号分支，确保迭代轨迹清晰可溯。

在变更移植关键流程上，提案优化了运行 CR（基线 CR）与当前版本的同步机制。以 Release 19 规范为例，其运行 CR 初始基于 Release 18 v18.4.0 创建，当 Release 18 迭代至 v18.5.0、v18.6.0 等新版本时，通过 Git merge 可将新增变更快速合并至 Release 19 的草稿分支，实现跨版本同步。针对可能出现的 “当前版本 CR 修复 bug 与新发布 CR 未适配” 的跨版本冲突，提案明确需优先保障当前版本修复成果，避免变更移植过程中出现功能回退。

值得注意的是，提案还展示了发布周期内的并行管理模式：以 Rel-21 与 Rel-22 为例，Rel-21 的规范维护工作与 Rel-22 的规范性开发可同步推进，维护类 CR 经审批后合并至对应版本分支并打标签，工作项分支成熟后则合并至新一代规范的草稿分支，最终迭代为正式版本。这种设计既保障了 legacy 版本的持续优化，又不影响新一代规范的开发进度。

业内认为，若该提案获得通过，将显著提升 3GPP 规范迭代的透明度与可追踪性，尤其适配 6G 技术研发中多版本、多团队协同的复杂场景，为 3GPP 工具链的现代化升级提供重要支撑。目前，该提案已作为议程项 6 提交审批，后续将根据 3GPP 会议讨论结果进一步完善。

微信关注我们

原文链接：https://www.oschina.net/news/398418

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

LFM2.5-1.2B-Thinking 发布：仅占用手机 900 MB 内存

Liquid AI 宣布推出 LFM2.5-1.2B-Thinking 推理模型，仅占用手机 900 MB 的内存，却能提供同等体积下最快的推理速度和最佳的推理质量。根据介绍，LFM2.5-1.2B-Thinking是LFM2.5 系列的最新成员。它是一个拥有 12 亿参数的模型，专门针对推理任务进行训练。它会在生成答案之前生成思考轨迹，系统地解决问题。该模型利用 LFM 独特的推理速度优势，生成更高质量的答案。与 LFM2.5-1.2B-Instruct 相比，LFM2.5-1.2B-Thinkin 有三项能力大幅提升：数学推理（MATH-500 上的 63→88）、指令遵循（Multi-IF 上的 61→69）和工具使用（BFCLv3 上的 49→57）。公告称，尽管参数量减少了 40%，但 LFM2.5-1.2B-Thinking 在大多数推理基准测试中表现与 Qwen3-1.7B 相当甚至更优。此外，它兼具高质量和高效的测试时计算能力。与 Qwen3-1.7B（思考模式）相比，它在提供更高整体性能的同时，所需的输出 token 更少。在推理阶段，LFM2.5-1.2B-...

2026-01-21

2

谷歌的搜索团队再近日次对 LLMs.txt 文件发声，澄清了关于其使用和官方立场的疑问。事情起因源于 Bluesky 上有人问，谷歌的一些产品仍然保留着 LLMs.txt 文件，是否意味着谷歌某种程度上的认可。对此，谷歌搜索团队的 John Mueller 给出了明确的否认：我本想说些刻薄话，毕竟这事提过太多次了，但直说吧 —— no。几周前，谷歌使用的内容管理系统（CMS）平台开始支持 LLMs.txt 文件，并将其添加到谷歌的许多开发者文档中。这其中也包括谷歌搜索的开发者文档，但添加后不久，搜索团队就将其从各自的开发者文档中移除。其他团队要么不在意，要么没注意到，所以保留了下来。 John 表示，这一文件的添加并不是出于谷歌的特别倡导，而是出于其他原因。他在 Bluesky 上的留言中指出，谷歌并不会使用这个 LLMs.txt 文件，甚至认为其可能是无用的，建议开发者如果使用，最好将其设置为不被索引。谷歌团队一直以来的立场是，LLMs.txt 文件并不被广泛使用，并且对于开发者而言，实际上可能没有什么实际价值。

2026-01-21

1

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。