Deprecate .status.succeeded and .status.reason

[imjasonh]

A step toward #517 -- if people are okay with this we can remove it in the next release (v0.5.0)

Changes

Marks .status.succeeded and .status.reason as Deprecated, updates some doc comments I noticed while I was in the area.

/kind cleanup

Submitter Checklist

• [n/a] Includes tests if functionality changed/was added
• [n/a] Includes docs if changes are user-facing
• [y] Set a kind label on this PR
• [y] Release notes block has been filled in, or marked NONE

See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.

Release Notes

BuildRun .status.succeeded and .status.reason are marked as deprecated in favor of .status.conditions.

[gabemontero]

We have an api-change label ... I would classify deprecation of fields in the api change category, even if the fields are not actually removed yet.

I added the label, but did not remove the cleanup label (though maybe we could). Conversely if there is consensus disagreement on my take, I don't feel strongly enough to argue much.

Thoughts?

[gabemontero]

/approve

I'll defer on lgtm to let a non-RH'er chime in for "multi-org" agreement.

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: gabemontero

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [gabemontero]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[SaschaSchwarze0]

/lgtm