Add fully-qualified labels

[alculquicondor]

Add a label for operator name.
Mark non-fully-qualified labels as Deprecated.

Fixes #148

Pending tasks to be done in future releases #149

[gaocegege]

/lgtm

It's clean.

[terrytangyuan]

/approve

[google-oss-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: terrytangyuan

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 [terrytangyuan]

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

[alculquicondor]

Can we have a new release of this repo?

[Jeffwan]

Can we have a new release of this repo?

@alculquicondor Here's the diff. v0.3.6...master I think we can cut one release or wait for more features. Can also use commit in go.mod?

[alculquicondor]

I would prefer we have a release than using a commit in go.mod

[gaocegege]

@Jeffwan WDYT, should we have a release after the all-in-one operator is merged?

[Jeffwan]

@gaocegege @alculquicondor I think it's ok to cut a release. We probably need to define release strategy for this repo.

I assume changes like #150 are breaking changes? If job controller is released, on going jobs will be affected.

Do we want to cut 0.3.7 or cut release branch 0.4.0? We didn't cut release branches for this version yet. I think it's time to follow semantic versioning?

[alculquicondor]

It's only breaking for the controllers that don't use the common controller. For the ones that do, the new controller still respects the deprecated labels.
But 0.4.0 makes the most sense

[Jeffwan]

Sounds good. Let's cut release-0.4 branch and cut 0.4.0 tag for the new release. sounds good to you? @gaocegege