“Release” is a loaded term. In this context, the interpretation we are interested in is the one most similar to GitHub Releases and GitLab Releases. That is because those both constitute hurdles to Radicle adoption. Teams that currently rely on GitHub|GitLab Releases will be looking for a similar solution as they migrate their projects to radicle.
Given this context, I would like to invite further discussion on the topic. Please feel free to point out any other existing discussions / ideas around this topic, so we can start dissecting and somehow forming a path forward.
@alexgood I believe you might be able to add some initial questions / comments?
The tweet you have referenced and your definition of “release” seem quite different. If I understand the twitter thread correctly then the question you are interested in solving is “how can we build a decentralised NPM registry on top of Radicle”? Is that right?
If so then I think the questions to answer are not about how to replicate Github’s releases page per se but more specific to javascript packaging, stuff like:
How are packages identified in such a registry, is it by URN?
Who hosts the HTTP API that people talk to? Do we need an http API? (I don’t know much about javascript packaging, is there a way to provide custom resolvers for packages in package.json?)
Javascript packages often have built artifacts that are distributed as part of the package, who builds these?
These are just the questions that pop into my head off the bat. But maybe I have misunderstood and you are thinking of some other usecase?
The tweet may have been the original prompt, but that is not what this discourse topic is about. I am interested in “Releases” as I qualified the term above.
By this definition, it’s already possible to create a release. One can create a git tag and publish it adding their changelog into the tag’s contents.
I suppose the interesting question becomes: how can the delegates show that they all approve this release tag? Or even more generally, what’s the mechanism for saying a tag – or multiple tags – are the canonical release(s)?
That is certainly a good first step, yes. Not sure how suitable the git tag message is for a full changelog, but it’s certainly a workable start! Is there any limit to an annotated git tag?
If not, maybe links to produced binaries that need to be part of the “release” could also be included in the git tag contents?
I think it’s probably worth asking what people who are blocked by the lack of a github style releases feature actually want. Because I can think of a few things:
A location on the web to publish a sequence of versions and a changelog
A service which hosts built artifacts corresponding to a particular release
Etc.
I think it’s worth enumerating these things because GitHub currently conflates a lot of these things into one feature because it’s convenient to do that in a centralised system. In a world where there isn’t one special git server it might not make sense to combine all these things.
I haven’t thought very hard about what exactly a GitHub release is useful for so it’s hard to break these components down, I would love to see a definition of a release that was more than “what GitHub does” (no snark intended, it’s just I can’t engage with that as a design goal).
Ah I didn’t think about binaries. But @alexgood makes a good point:
Do we really want to use the storage backend of radicle-link to store binaries or would it be better to build on top of other technologies and create bridges between them? I’m thinking something like IPFS and earning FileCoin for it where the stable location could be a trailer in the git tag, but merely spitballing here.
Oh agreed, this would be an awful idea. I assume the idea would be to have some kind of verifiable build process built on top of Radicle repositories. This is why I think we should enumerate what problems users want to solve, because there are lots of ways to do this with different tradeoffs and we can’t evaluate those without knowing what users care about.
From my experience, releases are useful as a means of communication from project maintainers → to project users. It is a way for maintainers to communicate sets of changes, rather than talking about each change made to the codebase individually. With a release, maintainers are essentially communicating to their users that they want them to use the new version of their software. More than anything, I see “releases” as an invitation by maintainers to users to … use the software.
Fully agree. I would also see the “build artifact hosting service” as a different service altogether.
Perhaps someone from the Growth team could help us out there? @nas I guess your team are the ones mostly talking to folks being onboarded to Radicle, so have you already had any discussions where teams mentioned the need for something like GitHub’s / GitLab’s releases? (If not, then this topic would probably be a good place to bring that feedback if it comes up).
I think maybe this is why I’m finding this conversation confusing - I think my understanding of what a release is, is very different to yours. To me a release is primarily a commitment from the maintainer to supporting something. The reason you would use a release vs just YOLOing off of master is that the maintainer will try not to break things for you as they change things and there is some idea that the whole thing works as expected. There is also generally an expectation that maintainers will notify in some manner if a release is found to be insecure, etc.
There are also interesting questions of supply chain security here as well. Things like cargo crev.
Maybe I’m unusual here, but it seems to me that a lot of people are going to think about these things when you say “release”, and thinking about how these things fit into the Link model is what I’m interested in.
I actually don’t think our views are that different here.
The reason you would use a release vs just YOLOing off of master is that the maintainer will try not to break things for you as they change things and there is some idea that the whole thing works as expected. There is also generally an expectation that maintainers will notify in some manner if a release is found to be insecure, etc.
These are all things that I had in mind when I wrote “invitation to users to use the software”. (When writing my previous reply I actually started making a list of things like these but then decided not to include it in my reply and use the “double-distilled” version of what a release is, so we don’t get caught up in the weeds of individual list items - trying to reach a higher-level agreement first.).
The only thing I am only a little reluctant to include into the release definition however, is any “commitment” by project maintainers, considering that it is open source software we are talking about here and most licenses explicitly prescribe “AS IS” use/delivery of the software and explicitly exclude commitments by maintainers. In a commercial setting that commitment is absolutely part of the game and so is support and back-porting fixes to older releases and security, etc. etc.
From reviewing the conversation, it seems that the concept of release needs to be refined into its more core components for this to be more productive. Each component can be discussed and thought about separately, but then perhaps composing them back again into the more “holistic” view of a “release”.
One component is the idea of maintainers tagging a specific snapshot of a project and saying this is a “release” point. I believe this is mostly solved by using tags, but I think how these things are verified can vary from project to project. For example, one project might want all delegates to create a tag of the same name and the release is verified by checking a quorum of signed tags point to the same commit. Or another project might just use a mechanical maintainer’s tag as the canonical release – after some CI/CD.
Another component is the release of a published artifact – this could be a binary or a library package. This distribution depends on where and how these artifacts get published. For example, Nix users might want to teach derivations how to fetch from Radicle hosted mirrors.
The point being that I think this discussion is too vague at the moment and as @alexgood said:
So perhaps we can break these into separate discussions of what you want to solve?
The only thing I am only a little reluctant to include into the release definition however, is any “commitment” by project maintainers, considering that it is open source software we are talking about here and most licenses explicitly prescribe “AS IS” use/delivery of the software and explicitly exclude commitments by maintainers.
I agree with this 100%, in theory. Like, if we are to define it, it should be defined as an “AS IS” agreement.
But if/when a developer starts utilizing Radicle components like Communities and Drips to take in communal funds for their work, I think – in practical terms – there will be some implicit commitment to deliver value to that community of users.
If the maintainer of a code base stops maintaining or updating, their community may start withdrawing Drips, funds will dry up, and there will be a financial incentive to continue maintaining/improving the code base.
I’m not speaking of legal commitments. Releases are a social commitment. One of the thing I think about when evaluating a dependency is what the maintainers attitude to their release schedule is. Whether they care about backwards compatibility, how they respond to issues raised on older releases etc. I typically check whether I already know who a maintainer is, go and have a look at the issue history and so on.
Please do include this stuff! It’s probably relevant here that I have never used Github Releases, I don’t have first hand knowledge of what people care about when they are using it. I think Fintan is correct that this discussion is very vague at the moment and it would be great if we could crystalise it around actual usecases where we know what people are trying to achieve.
For the record: Jit-Hub releases are actually created off of git tags. That is, a git tag is prerequisite to a Jit-Hub release, which in turn is nothing more than an unverified database entry providing some additional data.
They keyword here is “unverified”: the reason release objects are not stored in git itself is, presumably, that they can be modified and arbitrary files attached to them (well, maybe they are, but not in the same repo). By trusting a “Releases” entry, you trust Jit-Hub.
The only feature of “Releases” which cannot be modeled with git tags alone is the attachment of file artifacts. Oddly enough, it is possible to store large (binary) objects in git using Git LFS, and instruct Jit-Hub to include those in the generated tarballs. Naturally, Git LFS is not backed by decentralized storage, but there is no technical reason why it couldn’t be.
I follow the philosophy of Releases being a communication layer between maintainer and consumer. Tags are technically releases, but may not necessarily be apart of an official release.
Packages would contain artifacts, but also associated with a tagged release.
Looking at the GitHub screenshot. We can see that tags live under releases.
Maybe it would help if we had a framed example. My initial tweet was based on figuring out how to publish packages from the Design System I’m building.
when I think of a “release”, I think of a combination of 3 things:
the code (the - signed? - commit sha)
On this, I think we still need to resolve @fintohaps’ questions around maintainer consensus on what actually constitutes a valid “release tag”. A straightforward way to do this would be that each maintainer creates one signed annotated tag pointing to the same commit as all the other maintainers. And then we are just left with tackling the “what’s the mechanism for saying a tag – or multiple tags – are the canonical release(s)?” question that @fintohaps posed earlier.
the binaries (produced from that code with some well-defined, auditable process)
As it is possible to include hyperlinks to the binaries in the annotated git tag message, I think we are good here(at least for the Minimum Viable Product (MVP) version).
I would suggest descoping both “how do we produce these binaries” and “where do we actually host these binaries” from this particular discussion. These can both be discussed elsewhere.
the list of issues included in the release
Again, since writing the original message, @fintohaps has confirmed it is possible to use annotated git tags to include such a list of issues and other release notes / docs around migration etc. in the git tag message. I think that also covers my need.
With that said, would others here agree that the discussion here can be focused around just the mechanisms that project maintainers can use to communicate that a specific git tag (they have (all?) signed?) constitutes the “canonical release”?
Please note I am not asking for us to come up with all the possible options (different maintainers will go about this in different ways), I am just looking to document some possible options that this could work in a p2p / decentralized setting.
