Please release a new version so that the install instructions work

[TBBle]

> go get -u github.com/containerd/protobuild
go: downloading github.com/containerd/protobuild v0.1.0
go get: github.com/containerd/protobuild@v0.1.0: parsing go.mod:
        module declares its path as: github.com/stevvooe/protobuild
                but was required as: github.com/containerd/protobuild

This is fixed in main (#43), so this works, except for the deprecation warning.

> go get -u github.com/containerd/protobuild@main
go: downloading github.com/containerd/protobuild v0.1.1-0.20210923142138-6b023c693abe
go: downloading github.com/pelletier/go-toml v1.9.4
go get: installing executables with 'go get' in module mode is deprecated.
        Use 'go install pkg@version' instead.
        For more information, see https://golang.org/doc/go-get-install-deprecation
        or run 'go help get' or 'go help install'.

go install has the same problem:

> go install github.com/containerd/protobuild
go install: version is required when current directory is not in a module
        Try 'go install github.com/containerd/protobuild@latest' to install the latest version
> go install github.com/containerd/protobuild@latest
go install: github.com/containerd/protobuild@latest: github.com/containerd/protobuild@v0.1.0: parsing go.mod:
        module declares its path as: github.com/stevvooe/protobuild
                but was required as: github.com/containerd/protobuild
> go install github.com/containerd/protobuild@main
> 

(Sorry for the blank issue report, turns out pressing enter in the title box submits the issue)

[AkihiroSuda]

This will be probably after merging #45

[kzys]

1beadfd could be used as 0.2.0.

[kzys]

@stevvooe How about cutting 0.2.0 after merging #50 and #51?

[stevvooe]

@stevvooe How about cutting 0.2.0 after merging #50 and #51?

Yes! Do you have the process for doing that?

[kzys]

The only release we have was made by @crosbymichael.

@dmcgowan / @estesp - Do we have a containerd org-wide release process?

[estesp]

For subprojects we have no formal release process; it has been any maintainer tagging and pushing the tag, with whatever small bit of coordination is required (depending on the project) for updating vendoring in the consuming projects.

This is extremely lightweight and should be, unless we need to support a prior "release" line for compatibility reasons (like we do with ttrpc & cgroups); I assume that isn't necessary here.

[kzys]

Resolving since we have https://github.com/containerd/protobuild/releases/tag/v0.2.0.