Membership request for Zig Package Manager

[andrewrk]

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 https://github.com/semver/semver/blob/d460299638d3d2af6fcf809285dc6a469e15742a/CONTRIBUTING.md#participation-commitment

Regards,
Andrew

[steveklabnik]

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

[isaacs]

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]

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

[andrewrk]

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.

[segiddins]

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.

[JohnTitor]

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]

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!