Create initial public release

[fulldecent]

Please create a proper "1.0" or "0.1" release for this product.

Also adopt a policy of committing to backwards compatible releases using SerVer policy.

As current, nobody should adopt multicodec in their applications because there is no guarantee that multicodec is a fixed target.

[vmx]

I think indicating breaking changes makes sense.

I don't think there should ever be a 1.0 release of this repository. The 1.0 release will be a thing that is properly standardized through a standardization organization.

In the meantime we could use 0.x version and use the de-facto standard way of bumping "x" when there is a breaking change. To make the overhead as little as possible, there won't be any intermediate releases, but you could do you own, with appending the data and/or the commit.

Practically this means we release a 0.1 version now and probably won't release another version anytime soon.

@Stebalien what do you think about that idea?

[Stebalien]

I'm not sure about semver, or even versions in general. We'll never have a 2.0 and we're already effectively 1.0.

We should have an explicit policy but it's not going to be as simple as "once a code is allocated, it is never changed". I don't want to lock us into not fixing bugs/conflicts due to an overly strict policy.

We should probably have "status" markers like in https://github.com/multiformats/multibase/. That would also let us easily merge experimental codes and remove them later if they don't end up being used.

[fulldecent]

It will be great to get this to a standards body. But it is NOT necessary that you reserve 1.0 for that release. In fact, that is the worst policy, it means nobody should use your specification until they are ratified -- but also, of course, nobody should ratify a standard that nobody uses.

---

I am working on blockchain systems. These are deployed with an expected lifetime of forever and upgrade is impossible. This means it is incompatible with specifications that might change.

Based on the current progress of this project, I recommend that 1.0 should be released immediately and new things happen in the future. Yes, it is a good idea to call out that certain items are "experimental" and they are "non normative" per the specification.

[mikeal]

Our plan is to standardize this at the IETF. Once it’s published we’ll get an IANA registry for the multiformat table the spec will reference. The IANA registry will have a documented process for new entries.

In this case, semver is a not really relevant, the spec will have an RFC number and that will be that. It won’t ever change, changes would need to be a new spec and either reference the existing IANA registry or a new one.

[vmx]

I'm in favour of having a status field, which we then can also use in the IETF spec (it's currently not part of it, but I hope we can add that also later in the process). Adding a status field in this repo now also gives us a bit of freedom before we commit to definitive definitions/rules of what "status" means.

[vmx]

I should've added that I did a bit of research whether such a status field would be possible within an IANA registry. My conclusion is yes.

• https://www.iana.org/help/protocol-registration gives a good overview, examples and answers a lot of questions about how things work
• https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml Even URI Schemes have different categories. I think that's similar to what we intend to do
• https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml has even a termination date field, which could also be an option (not one I'd use in our case, I just mention it for completeness)