Appearance
Appearance
直到 2008 年 3 月,事情都很简单。Wireshark 仍处于 Beta 开发阶段(过去 10 年一直如此),新的 beta 版本会不定期但通常以较短间隔出现。这些新 release 与前一个版本一样,只是应用了一系列 patches。这些 patches 来自乐于贡献的志愿者、发布其工作的公司和/或 core developers 群体。这个群体帮助原作者 Gerald Combs 开发新功能并处理不断传入的 patches。
随着 2008 年到来,Gerald 认定 Wireshark 已经达到足够成熟、可以授予 Stable 状态的阶段。这标志着 Wireshark 及其 core developers 开始进入稍微复杂一些的阶段。
Release Policy 定义了 core developers 之间达成的一组约定,以确保 release 内容一致。这意味着对于最终用户来说,某个软件 release 中可以找到什么必须是可预测的。该内容由 Gerald 与 core developers 和用户社区合作定义。
Stable release 被定义为一组一致的源文件,这些源文件与指定的 libraries 一起,实现当时可用的 functions 和 features。2008 年 3 月,第一个 Stable branch 从源代码的主 Development trunk 中分离出来。当然,这些直接来自 Development trunk 的代码既不一致,也没有 bug free。随后进行了额外工作来稳定代码,因此在几个 pre-releases 之后,第一个 Stable release 发布了。
在这个 Stable release 的生命周期中,不可避免地会发现问题并提出 bug fixes。这些 fixes 会在 Development trunk 中开发和测试,然后被安排 back-port 到 Stable branch。当收集到足够多的 bug fixes,或者 bugs 的严重性需要时,并由 Gerald 酌情决定,将在 Stable release branch 上准备一个新的 Maintenance release。这个 Maintenance release 必须遵守同样的 release 内容一致性策略,因此不包含新的或改变的 features,只包含对已检测到缺陷的修复。唯一允许的其他更改是对易变数据文件的更新,例如 manufacturer database、enterprise numbers 等。
当新的 Stable release 从 Development trunk 中分离出来时,必须决定上一个 Stable release 的命运。它可以被 Abandoned,以支持新的 Stable branch;也可以被 Retired,这意味着它会继续获得保持正常工作所需的关注,但不会更多。
release 生命周期的当前状态可在此处找到:Development/LifeCycle。
除了 Stable branches 之外,Development trunk 会继续存在,收集 bug fixes 以及新的和更改的 features。所有这些 committed changes 都会触发一次 automatic build,以验证源代码的一致性,并为 power users 提供使用 features bleeding edge 的选项。
在可行时,Gerald 可能决定发布一个 Development snapshot release,以便让开发中的 features 获得更多曝光。
赋予软件的 release numbers 表示该软件的状态。这里对此进行了说明:Development/ReleaseNumbers。
该策略的目的是为用户提供稳定的软件。不仅仅是“它不会崩溃”意义上的稳定,还包括“interfaces 不会变化”意义上的稳定。虽然这种稳定性对只使用 GUI 的人可能并不重要,但对某些用户来说很重要,例如,他们会基于 tshark 的输出来自动化测试网络产品。这对许多 Linux distributions 也很重要,这些 distributions 的策略是在某个(distro)版本的生命周期内不进行(重大)软件版本升级——大概也是出于同样的基本原因:保持 interface stability。例如,Fedora 的 Updates Policy for Stable Releases 表示,一旦发布 stable release,就只应对 package 进行 bug fixes。
通过维护 stable branches,Wireshark 开发团队帮助确保 Linux 用户(至少是那些从其 distribution 获取 Wireshark 的用户)能够获得重要的 Wireshark bug fixes;如果 stable branches 没有像现在这样长期维护,Linux distributions 很可能只会应用其用户报告的 bug fixes(包括 security fixes)(如果它们还会更新 Wireshark 的话)。通过维护 stable branches,Wireshark 开发团队能够控制这些用户获得哪些 bug fixes,同时让 distributions 的工作更轻松。
该策略确实有一个副作用,即新的 stable branches 并不是非常常见;最近,新 branch 大约每年在 Sharkfest 用户和开发者会议期间创建一次。对于那些(interface)stability 并不重要但希望更早获得新 features 的用户,development snapshots 很可能是最佳答案。
即将发布的软件 releases 的日期和内容概览的粗略规划在此给出:Development/Roadmap。
Imported from https://wiki.wireshark.org/Development/ReleasePolicy on 2020-08-11 23:13:03 UTC