ZIG是一种通用编程语言和工具链，用于维护健壮、优化和可重用的软件。
现在，在Zig软件基金会的支持下，这个项目不仅在财务上是可持续的，而且还为4个人提供了付费合同时间，很快还会更多。
这个版本的特点是7个月的工作和来自187个不同贡献者的更改，分布在2666个提交项中。
ZIG使用分层系统来传达对不同目标的支持级别。值得注意的是，在此版本中：
Zig不仅可以为这些目标生成机器码，而且标准库跨平台抽象也可以为这些目标生成实现。因此，编写一个不依赖libc的纯Zig应用程序是可行的。
CI服务器在每次提交到主分支时自动测试这些目标，并使用指向预构建二进制文件的链接更新下载页面。
所有的行为测试和适用的标准库测试都通过了这个目标。已知所有语言功能均工作正常。
标准库支持此目标，但某些API可能会给出不支持的操作系统编译错误。您可以链接libc或其他库来填补标准库中的空白。
这些目标是已知有效的，但可能不会自动测试，因此偶尔会出现倒退。
在我们争取第1层支持的过程中，可能会禁用这些目标的某些测试。
这些目标并不经常被测试；人们很可能需要为ZIG做出贡献，才能为这些目标做出贡献。
如果该目标是由LLVM提供的，则LLVM可能将该目标作为实验目标，这意味着您需要使用Zig提供的二进制文件才能使用该目标，或者使用特殊的配置标志从源构建LLVM。ZIG目标将显示该目标(如果该目标可用)。
这个目标可能会被诸如MacOSX/i386这样的官方政党认为是不赞成的，在这种情况下，这个目标将永远停留在Tier 4中。
我很抱歉-由于个人生活事件，我没有时间完成这些发布说明。我的计划是在1-3周内发布0.7.1错误修复版本(当里程碑中的问题得到解决时)，并在那时完成0.7.0版本说明(仅输入版本说明就需要一周多的时间)。
这个版本的LLVM将AVR提升到了一个非试验性的后端，因此Zig的AVR后端现在可以通过这个版本广泛使用。
感谢LemonBoy向LLVM和Clang提交了几个补丁，以修复与zig相关的错误。
因为交叉编译是一流的用例，Zig尽可能提供libc，而不是依赖于宿主libc。
Zig现在为MacOS提供了libc头文件，因此可以针对MacOS交叉编译C代码。此外，对于原生MacOS版本，在编译C代码时对Xcode的依赖性减少了一项。
请注意，由于LLD的缺陷，MacOS上的链接仍然存在问题，但在这方面正在发生两件事：
Zig附带了MUSL的源代码。选择MUSL C ABI后，Zig将从源为所选目标构建MUSL。
除了其他42个Glibc版本之外，Zig还获得了瞄准Glibc 2.32的能力。
在此版本中，Zig对Glibc的支持得到了改进，可以在本机检测到的Glibc版本比Glibc 2.32更新时轻松处理。在这种情况下，Zig将尽其所能构建最新版本。
Zig附带了mingw-W64的源代码。当以*-windows-gnu为目标并链接到libc时，Zig从源代码为所选目标构建mingw-w64。
这个发布周期的主要焦点是自托管编译器。这里有很多要谈的：
提到Stage2编译器的体系结构，并注意主要贡献者已经开始致力于它的各个部分。
在过去的6个月里，MacOS的发展是混乱的，Big Sur的重大突破性变化和即将推出的aarch64硬件的发布。
Jakub Konka已经购买了一套苹果开发套件，并一直致力于为该系统提供Zig支持。ZIG程序可以在这个系统上运行，但是它们需要一个变通方法来利用系统链接器，而不是LLD。下一步是对该系统进行LLD改进，以及Jakub一直在开发的Zig自托管链接器代码。
齐格还不成熟。即使使用Zig 0.7.0，使用Zig进行一个重要的项目也很可能需要参与开发过程。
不太可能会有0.7.1，但计划会有0.8.1。
Alex是ZLS背后的主要开发者。他辞去了土木工程的工作，希望将自己的职业生涯过渡到编程领域。Alex贡献了PE/COFF(Windows)自托管编译器代码，他是下一个申请付费承包时间的人。
Jakub一直在不知疲倦地致力于MacOS支持，改善了在平台上使用Zig的体验，并贡献了Mach-O#{link|Self-Hosted Compiler#}代码。
你可能会认出SpexGuy在#Zig-Help Discord频道闲逛，并耐心地回答非常详细的问题。
我很高兴地宣布，他现在是我们最新的付费贡献者，他的主要精力是致力于官方Zig语言规范的初稿。
这是一个新的进展，所以他还没有时间取得重大进展。
根据0.6.0路线图，0.7.0版本的主要主题应该是稳定语言、创建语言规范的初稿以及自托管编译器。
我们已经朝着这个目标迈出了很大的一步，你可以从Self-Hosted Compiler和Martin SpexGuy&34；Wickham致力于语言规范的工作中看到这一点。然而，仍有很多工作要做。
0.8.0发布周期的主要目标是完成自托管编译器并发布它，删除Zig的C++实现。如果您关心自举，请参阅此问题：#6378：允许O(1)自举功能暂时回归。
在Zig编译器中内置包管理器是期待已久的特性。ZIG 0.7.0没有此功能。
如果包管理器运行良好，人们就会使用它，这意味着构建Zig项目将涉及编译更多行的Zig代码，这意味着Zig编译器必须变得更快、更擅长增量编译、更擅长资源管理。
因此，包管理器依赖于完成自托管的Compiler，因为它计划具有这些改进的性能特征，而Stage1没有这样的计划。
此版本的Zig有意退化C头文件生成功能。它和19,216行其他C++代码一起被删除了(幸好！)。该功能将被重新添加，但仅限于自托管编译器。
如果你想对Zig的前进方向有更多的了解，你可以看看这组被接受的提案。
特别感谢LavaTech的Ave和露娜，他们为我们的持续集成管道托管了SourceHut的一个实例，但其RAM超过了主要sr.ht服务所允许的范围。多亏了这一点，FreeBSD现在有了更多的测试覆盖范围，最引人注目的是所有标准库测试。
特别感谢那些赞助Zig的人。因为你，Zig是由开源社区驱动的，而不是以盈利为目标。特别值得一提的是，这些优秀的人会以每月50美元或更多的价格赞助Zig：