ability to roll zig major version without causing problems for downstream users

[andrewrk]

Here's how this is going to work:

Applications and libraries must specify which Zig major version they are targeting. When Zig 1.0.0 comes out, there will only be 1 value possible for this, which is 1. But when 2.0.0 comes out, you can choose 1 or 2.

When Zig 2.0.0 ships, it ships with a copy of the standard library from the latest 1.x.y series, and the compiler itself knows how to parse and analyze 1.0.0 code differently than 2.0.0, and so on for the rest of the major version releases.

And that's it, that's the whole plan.

It'll be possible to have an application which needs zig version 3.x.y depend on a package which needs zig version 1.x.y which depends on a package which needs zig version 2.x.y. However, it will be better to update to the newest version, because using copies of the standard library can bloat the application size.

So you would always want the newest zig release, and you'll continue to get consistent compilation behavior because of explicitly asking for a specific version when you build.

[MasonRemaley]

This seems like a good solution--the only potential issue I can think of is if I'm a library author and Zig v2 comes out but doesn't break my Zig v1 library. Do I start targeting Zig v2 and bloat all of my current users's projects? Or do I leave it and bloat all future users?

If this seems like a real problem you could potentially allow people to specify multiple supported versions of Zig, but there would be some subtleties there around deciding which supported version to use when compiling. I think just using the most recent version supported by the library that's installed on the current machine might work?

[andrewrk]

In this situation, I expect library authors to immediately start targeting the new Zig version. The library's previous release is tagged with the previous Zig version, so code which depends on a particular release of the library continues to work, and we all want to try to get to the latest version of everything as soon as practical.

The agreed-upon version of Zig for purposes of not bloating is always the latest version.

[andrewrk]

With the way package management is proposed in #943, a zig 2.0.0 standard library could minimize bloat by detecting the presence of older versions and utilizing the compatible components.

[andrewrk]

Superseded by #6466