Zig: Zig-2021 vs Zig-1.0: Using year based version numbering

[user00e00]

It is a matter of preference, but I would like to see "year based" version numbering once zig is out of beta, with version numbers looking something like this:

• Zig-2021-0.0, first release
• Zig-2021-0.1, first bugfix release
• Zig-2021-1.0, first improvement release
• ...
• Zig-2024-0.0, first "breaking" release.

Here are the associations I would get from different version numbers:

_Zig-2021,_ the "standard" set by the first version of Zig, which is great for most use cases, keeps getting support, but was released ASAP to get something workable out there that people can depend upon (instead of C), while risking that the design decisions might not sufficiently cover all use cases.

_Zig-2024,_ the refined standard that while making some breaking changes, could take real world usage into account and make final language adjustments that might be crucial for some (but not all) use cases.

_Zig-1.0_, The first version of Zig, but Zig-2.0 is gonna be twice as good! I will have to upgrade.

_Zig-2.0._ The second version of Zig, but Zig-3.0 is gonna be 50% better! I will have to upgrade.

TLDR: Incremental version numbering gives the impression of something bound to be replaced, while year based numbering gives the impression of something being a standard.

Final thoughts, if it would be very straight forward for an imagined Zig-2024 project to include (imagined) Zig-2021 packages as dependencies, then Zig could be a "stable" language, yet not have to stop evolving after the first release.

[mikdusan]

when 2021 is released, why would we need anything except bugfix release numbers? e. instead of 2021-1.0 just 2021-0 and next is 2021-1 . there will never be 2021-0.5. new features in a language are breaking once the language is stabilized.

• hey Joe, here's my 2021-1.5 code, give it a shot. thanks Joe but I can't, we're at 2021-1.0

• hey Joe, here's my 2021-1 code give it a shot. thanks Joe, works on our 2021-0 systems because they're FreeBSD and it doesn't have a need for -1 bugfix.

edit: I'll just add to summarize my thoughts: Zig has a stable number. Be it 1 or year based as 2021 or 2-digit year based 21, a delimiter and a maintenance number. And the choice of stable number { 1, 2021, 21 } delimiter { ., - } maintenance { int, hex, char } is cosmetic. My cosmetic pref is 21.int or 21.0 just because I don't much care about year 2100 and everyone before that will instantly now how new the language is.

[user00e00]

With improvements, I was thinking in terms of improved compilation speed and so on. Not any changes to language semantics or syntax.

I agree that there's redundancy to it though. Zig versioning doesn't have to follow the breaking:enhancement:bugfix convention.

[zamadatix]

As long as the future stable Zig release schedule guarantees there would never be 2 breaking releases in a year then I think it makes sense from the perspective "breaking" in `breaking:enhancement:bugfix" doesn't have to go up by 1 it just has to go up by some value. With that in mind year would seem perfectly acceptable and would help give extra context to how old a given version is.

[mikdusan]

ah yes good point; the weakness of tying major to year is it precludes 2 major releases in a year. I'm strangely ok with that.

[andrewrk]

Closing in favor of status quo, which is semver.

The version number applies to:

• the language
• the standard library, including zig build API
• command line options

Each with their own definition of what constitutes "breaking".

See also #350.