Follow the go convention with tags.

[boris-smidt-klarrio]

Is your feature request related to a problem? Please describe.
When including the api of openshift everybody needs to use a replace in the go mod since it doesn't use the proper go.mod convention causing issues when people include your library as a transitive dependency. like the grafana-operator.

Describe the solution you'd like
When including this package you shouldn't be adding a replace in your go mod.

[leecalcote]

We're running up against a similar problem:

go: warning: [github.com/openshift/api@v3.9.0+incompatible:](http://github.com/openshift/api@v3.9.0+incompatible:) retracted by module author: v3.9.0 is the only tag in openshift/api and it was created before go.mod was
go: to switch to the latest unretracted version, run:
        go get [github.com/openshift/api@latest](http://github.com/openshift/api@latest)

[mitchellmebane]

This would be nice, since the replace directives break go install for tools like Kompose.

[sebrandon1]

+1 I would love if this repo had proper semver versioning and releases.

[JoelSpeed]

You should be able to avoid a replace by using

go get github.com/openshift/api@master

Or replacing master with any other appropriate branch (e.g. release-4.20 if you're building for the 4.20 version of the project)

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale