最近在网上看到这样一个内容

https://developer.horizon.ai/forumDetail/118363914936419003

关于J5/J3/J2平台的底层软件地平线内部的释放计划和形式？

=====

您好：

问题如题，我们当前在地平线J5平台展开进行的项目居多，跟贵司接触和合作的部门也不仅仅是点对点的合作。

产品形态也不完全一样，但共同点是都基于J5平台；

我们分阶段、分项目、分平台拿到过不同版本的J5底层软件BSP包，地平线同事关于此软件包对我们的释放形式也不尽相同（有压缩包的形式，也有gitlab的形式，还有只针对某一版硬件的形式进行的释放）；虽然这些代码释放是白盒或者灰盒释放的，但释放之前，在地平线内部关于此版本的背景和关联关系我们外部客户并不清楚。

作为商业公司里的开发者而言，我们拿到一套J5代码以后需要公司内部去建立我们自己的代码仓库，用于展开去做开发和迭代，需要长期维护。

但我们的角度，同样是J5，它应该是基于同一套base进行的释放，但我们拿到的代码包之间没有关联性，所以无法进行所谓的“基线升级”；

这就导致我们内部同一个J5平台，需要维护好几个仓库，若干个分支，这样很不利于我们在J5上的持续迭代开发，维护成本也较高；

所以，基于上述背景，请问下地平线的同事：

1.地平线内部是否在考虑将J5在内部首先统一成一个base？是否有基于此统一基线的释放计划和里程碑节点？

如果有，是否可以简单介绍下大概计划？如在大概哪一个时间点可以达到内部基线统一，哪一个时间点可以进行对外释放？

2.在对外释放时，是否考虑形式上的统一，或者让客户可以进行选择？

如整个代码包的形式释放，但同时也提供基于如001版本到002版本之间的差异patch，供客户自行决定合入哪些patch，可以与地平线的主基线对齐。

3.由于地平线是一家芯片公司，在产品形态或生态规划上肯定比下游的客户公司的路线要复杂，那么是否存在将J5或J2/J3平台进行不同产品形态的区分？

如同样的J5平台，在软件基线或版本上，区分车载版本和非车载版本？

目前我个人的感觉是分不太清楚，甚至某一版本的软件，我们都无法区分此版本是支持单J5的，还是支持DualJ5的。

以上，烦请简单介绍下，或是否有类似的文档可以share一下供开发者对地平线的产品有一个清晰的认识。

感谢！

=======

官方回答：

非常感谢贵公司对地平线征程系列芯片的信赖和持续投入。我是地平线芯片解决方案的项目负责人，凌坤。 

您现在拿到的不同形式的软件包，应该是因为在BSP研发阶段内外部不同产品/技术项目，发布给合作伙伴的联调/测试/迭代版本不同导致的。很抱歉，我们在不同阶段和项目中给贵公司的释放形式不同，给您和团队带来困扰。  随着J5量产落地，BSP内外部协同也在持续迭代优化中，结合您提出的问题，介绍如下：

1. 关于统一base、释放计划和里程碑节点：  

地平线内部是统一的芯片基础bsp，过去因为项目多数是评测/开发/调试，BSP处于持续开发阶段，因此就按照不同项目扩展功能后分别交付，存在形式多样，合作伙伴多项目开发难协同的问题。

随着J5更多量产落地，内部正在对扩展功能共基线统一管理，采取敏捷开发方式，收敛统一对外交付形式。计划本月完成内部共基线统一开发管理，2023年Q1测试迭代后对外释放。 

2. 关于释放形式：

为适配不同合作伙伴，不同项目协作形式的需要，**释放形式还会有多种，但整体会收敛**。如压缩包、gitlab等，同时也会有产品配置上的区别，如有功能增强的车载版本 和 非车载版本。

后续我们规划有定期的基线版本释放，也会将个别基线版本会作为长期维护版本，在一定时间周期内提供基于基线版本的关键bug fix patch供客户自行选择。以确保客户/合作伙伴的产品版本维护简单，成本低，追溯易。

3. 关于产品形态区分：

软件对外释放的形态，会依据项目类型而异。

比如会提供相对开放的非车载 BSP版本的释放方式，但该版本不能用于量产产品中。  

车载版本的BSP还需要通过地平线的单独渠道申请，以获得保质保量的支持。

关于您提到的，一个版本的软件，无法区分单J5 还是Dual J5等易用性问题，我们也在持续迭代优化中，有进展或者对外释放的消息，将第一时间同步给贵团队。

再次对我们不同的发布形式给贵团队带来的困扰表示歉意，相信2023年Q1的释放版本及后续迭代能提升贵团队的开发体验。也欢迎您持续通过社区，我司相关对接人员，对地平线芯片解决方案（BSP/OS/基础软件、工具链）给与关注、支持和反馈。您的宝贵意见建议和反馈对我们至关重要， 谢谢！

======

因为工作的原因，我们需要和芯片原厂对接，也有遇到sdk的释放的问题，记得刚开始和RK合作的时候，我们是寄U盘给RK那边帮忙拷贝SDK源码的。之后就在这套代码上不断的迭代更新，有遇到更新的补丁，就分开的打进去，当然，也有对应的repo方式拉取代码，但是速度实在不敢恭维。

如果是安卓SDK，因为安卓版本在不断的迭代，一个平台可能有几个不同的SDK版本；而且每个芯片也有迭代，就好比一个芯片3xx9，可能会有3xx9y、3xx9b等版本，不同的版本上可能还有一些小的差异。

不过问题总是有解决的办法的，只是解决的方式会不尽相同。

比如拷贝代码，可以先给一个基础版本在网盘里，然后可以通过基础版本同步主线的代码，还有原厂的代码服务器也挺垃圾的，原厂可能有些技术上的不想公开源码「这个做法对于开发者来说挺不友好的」，我相信之后肯定是开源做得越好的公司会越得到认可。大家也都知道基础技术是哪里来的，藏着掖着也不是一回事。

对接的人对接的方式最好制定下来后不要轻易更换，不管是好还是不好，先按照一个可执行的方式进行，因为工作也有遇到过这样的问题，不管的更换带来的学习成本挺高的。

不管做什么项目，尽量做到代码和配置分开，不同的项目可以用同一个代码，程序员在做功能的时候也最好用开关来控制，一起维护统一份代码sdk，兼容对外的许多项目，从长远来看，问题会更少，对项目也会更好。

国产化的过程是艰苦的，我们现在遇到的每个问题，解决的每个问题，都会让国产的芯片走向越来越好，在很久之后，国产芯片用的人越来越多，势必也会有更大的立足之地。