【问题标题】:Are there any standards for versioning software that has multiple platform clients?具有多个平台客户端的版本控制软件是否有任何标准?
【发布时间】:2011-09-11 03:06:02
【问题描述】:

关于软件版本控制的大多数标准我都非常清楚。整个major.minor.revision/build/whatever 方案。但是我不太确定当软件可以安装在多个平台上时是否有任何约定,每次安装都有一个独立的周期。例如,我有一个具有以下客户端的应用程序: - 网络 - 桌面 - iPad - 移动的: - 苹果手机 - 安卓

所有这些客户端可能没有完全相同的功能,它们也不一定会同时发布到世界上。他们的进一步发布时间表也可能有所不同。那么,关于如何解决这个问题有什么建议吗?就像将它们全部分开一样简单吗?因此,在任何时间点,套件都可能如下所示: - appname-web 3.1.0 - 应用名称桌面 2.1.1 - appname-ipad 1.0.0 - appname-iphone 1.5.0 - appname-android 1.6.0

谢谢,

尼克

【问题讨论】:

  • 这是一个见仁见智的问题,完全取决于您的软件。您也可以选择不担心 Google Chrome 等版本号,而是在每个版本中递增。

标签: versioning standards clients


【解决方案1】:

这只是一个例子,但它可能是说明性的。 RedHat 包分两个阶段构建,首先将源代码收集到一个源包中,然后将 srpm 构建到每个支持的架构的一个二进制包中。名称和版本在源代码和所有不同的二进制文件中都是一致的;版本号代表输入。但是,arch 位于 RPM 容器中的不同字段中,并且仅存在于二进制包中,因为源包与架构没有任何关系。拱门是输出

除了 RPM 格式之外的其他捆绑或标记包的方式或多或少地使这种事情变得明确; windows 的安装程序只支持一种架构,windows。

tl;dr:版本和架构是不同的东西。您向用户提供的关于两者的线索取决于您的分发方法,但不要将两者混为一谈。

【讨论】:

  • 感谢您的回复。不过,我觉得它部分解决了我的问题。对于像在 Windows 和 Mac 上安装我的桌面客户端这样的事情,这是有道理的 - 源是相同的,但安装是不同的。但是,我的 iPad 和 Android 资源将在很大程度上脱节。除了一些共享的后端之外,没有任何东西可以连接它们。这两个平台的版本是否以任何形式保持同步是否重要?
  • 只有你,开发者才能回答。
猜你喜欢
  • 1970-01-01
  • 2012-06-10
  • 2011-03-27
  • 1970-01-01
  • 2011-01-26
  • 1970-01-01
  • 2019-12-27
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多