[GH-ISSUE #497] Membership request for Zig Package Manager #5485

New Issue

GiteaMirror · 2026-06-15T11:55:29-05:00

GiteaMirror commented

2026-06-15 11:55:29 -05:00

Originally created by @andrewrk on GitHub (Feb 12, 2019).
Original GitHub issue: https://github.com/semver/semver/issues/497

Greetings! I'm the creator of the Zig programming language, and currently in the design phase of the Zig Package Manager. I think I would have a
unique perspective to bring to the table, since the package manager
has this list of (to varying degrees of certainty) planned features:

fully decentralized
private key signed, distributed with public key attached, to provide
detection of author change
attached (and signed) release notes to read when upgrading
exact version locking with client-side checksum matching
SemVer with language support for having one package "override"
another package when they have compatible APIs.
Compiler-enforced API breakage detection (this is a complicated topic
which overlaps with SemVer)

I believe I would be a relatively conservative participant, providing insight and perspective to proposed changes, rather than proposing any radical new ideas.

I have read and I agree with d460299638/CONTRIBUTING.md (participation-commitment)

Regards,
Andrew

Originally created by @andrewrk on GitHub (Feb 12, 2019). Original GitHub issue: https://github.com/semver/semver/issues/497 Greetings! I'm the creator of the [Zig programming language](https://ziglang.org/), and currently in the design phase of the Zig Package Manager. I think I would have a unique perspective to bring to the table, since the package manager has this list of (to varying degrees of certainty) planned features: * fully decentralized * private key signed, distributed with public key attached, to provide detection of author change * attached (and signed) release notes to read when upgrading * exact version locking with client-side checksum matching * SemVer with language support for having one package "override" another package when they have compatible APIs. * Compiler-enforced API breakage detection (this is a complicated topic which overlaps with SemVer) I believe I would be a relatively conservative participant, providing insight and perspective to proposed changes, rather than proposing any radical new ideas. I have read and I agree with https://github.com/semver/semver/blob/d460299638d3d2af6fcf809285dc6a469e15742a/CONTRIBUTING.md#participation-commitment Regards, Andrew

GiteaMirror added the question label 2026-06-15 11:55:29 -05:00

GiteaMirror closed this issue

2026-06-15 11:55:30 -05:00

GiteaMirror commented

2026-06-15 11:55:31 -05:00

@steveklabnik commented on GitHub (Feb 12, 2019):

One of the goals for getting a good spec in place is to make it easy for new implementations in new languages to happen, and so I think having someone to represent this viewpoint makes a lot of sense. Additionally, we've known each other for a while, which helps.

I think a lot of these features are sort of outside of the spec proper, but that's not inherently a bad thing. Our various managers do some of these things too; we just need to be clear what's part of the spec and what's part of systems built on top of it. :)

@semver/maintainers , if you could check a box if you agree, or post a comment to this thread if you disagree and/or have questions to make sure @andrewrk is on the same page as the rest of us, that'd be great.

@anangaur
@dherman
@indirect
@isaacs
@segiddins
@steveklabnik

@steveklabnik commented on GitHub (Feb 12, 2019): One of the goals for getting a good spec in place is to make it easy for new implementations in new languages to happen, and so I think having someone to represent this viewpoint makes a lot of sense. Additionally, we've known each other for a while, which helps. I think a lot of these features are sort of outside of the spec proper, but that's not inherently a bad thing. Our various managers do some of these things too; we just need to be clear what's part of the spec and what's part of systems built on top of it. :) @semver/maintainers , if you could check a box if you agree, or post a comment to this thread if you disagree and/or have questions to make sure @andrewrk is on the same page as the rest of us, that'd be great. - [ ] @anangaur - [x] @dherman - [ ] @indirect - [x] @isaacs - [x] @segiddins - [x] @steveklabnik

GiteaMirror commented

2026-06-15 11:55:32 -05:00

@isaacs commented on GitHub (Feb 12, 2019):

Just to be 100% clear, things like package signing, distribution, signed release notes, and so on, are way outside the scope of SemVer.

I have no problem with having representatives from new package managers and new languages, especially if you're going to be managing a SemVer implementation as part of that. But we do have to stay focused about exactly what it is we're doing here.

A successful outcome, in my opinion, would be getting to a place where, like most mature SemVer implementations, there isn't much change, and newcomers have a clear set of guidelines for how to match the rest of the established implementations.

Since even small changes to a community protocol can be so disruptive, SemVer itself should not change much at all, and is, in my opinion, nearly complete. (There are some well-trod cowpaths to pave, but that's about it.)

For broader discussions of package management, I'd recommend the http://package.community/ discord.

@isaacs commented on GitHub (Feb 12, 2019): Just to be 100% clear, things like package signing, distribution, signed release notes, and so on, are _way_ outside the scope of SemVer. I have no problem with having representatives from new package managers and new languages, especially if you're going to be managing a SemVer implementation as part of that. But we do have to stay focused about exactly what it is we're doing here. A successful outcome, in my opinion, would be getting to a place where, like most mature SemVer implementations, there isn't much change, and newcomers have a clear set of guidelines for how to match the rest of the established implementations. Since even small changes to a community protocol can be so disruptive, SemVer itself should not change much at all, and is, in my opinion, nearly complete. (There are some well-trod cowpaths to pave, but that's about it.) For broader discussions of package management, I'd recommend the http://package.community/ discord.

GiteaMirror commented

2026-06-15 11:55:32 -05:00

@isaacs commented on GitHub (Feb 12, 2019):

I guess I'm not disagreeing with the content of @steveklabnik's message, just the "sort of"-ness of it. ;)

@isaacs commented on GitHub (Feb 12, 2019): I guess I'm not disagreeing with the content of @steveklabnik's message, just the "sort of"-ness of it. ;)

GiteaMirror commented

2026-06-15 11:55:33 -05:00

@andrewrk commented on GitHub (Feb 12, 2019):

Just to be 100% clear, things like package signing, distribution, signed release notes, and so on, are way outside the scope of SemVer.

100% agree, and a big part of my motivation for joining the team would be to keep it that way. That's what I meant by this:

I believe I would be a relatively conservative participant, providing insight and perspective to proposed changes, rather than proposing any radical new ideas.

I just want to make sure any updates to the spec don't prevent these package management goals inadvertently.

@andrewrk commented on GitHub (Feb 12, 2019): > Just to be 100% clear, things like package signing, distribution, signed release notes, and so on, are _way_ outside the scope of SemVer. 100% agree, and a big part of my motivation for joining the team would be to keep it that way. That's what I meant by this: > I believe I would be a relatively conservative participant, providing insight and perspective to proposed changes, rather than proposing any radical new ideas. I just want to make sure any updates to the spec don't *prevent* these package management goals inadvertently.

GiteaMirror commented

2026-06-15 11:55:34 -05:00

@segiddins commented on GitHub (Feb 12, 2019):

I just want to make sure any updates to the spec don't prevent these package management goals inadvertently.

Strong agreement there, and I think it's also important to have a spec thats conducive to those broader goals, without prescribing anything specific.

@segiddins commented on GitHub (Feb 12, 2019): > I just want to make sure any updates to the spec don't _prevent_ these package management goals inadvertently. Strong agreement there, and I think it's also important to have a spec thats conducive to those broader goals, without prescribing anything specific.

GiteaMirror commented

2026-06-15 11:55:35 -05:00

@JohnTitor commented on GitHub (Jul 27, 2022):

Hey @andrewrk, sorry for the long delay, but it seems there's no objection and I'd like to call it the consensus. Let me know if you are still interested in helping the semver work! We'll then add you to the team as per https://github.com/semver/semver/blob/master/CONTRIBUTING.md#the-semver-team.

@JohnTitor commented on GitHub (Jul 27, 2022): Hey @andrewrk, sorry for the long delay, but it seems there's no objection and I'd like to call it the consensus. Let me know if you are still interested in helping the semver work! We'll then add you to the team as per https://github.com/semver/semver/blob/master/CONTRIBUTING.md#the-semver-team.

GiteaMirror commented

2026-06-15 11:55:35 -05:00

@JohnTitor commented on GitHub (Oct 5, 2022):

I will close this as there's been no response for over 2 months. Feel free to reclaim if you're still interested in the semver spec maintenance!

@JohnTitor commented on GitHub (Oct 5, 2022): I will close this as there's been no response for over 2 months. Feel free to reclaim if you're still interested in the semver spec maintenance!

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#5485