Cut 1.2.0 tag and release a stable version of master

[Jeffwan]

I think it's a good time to consider merging all-in-one-operator back to master branch and keep evolving the development.

1. I would suggest to cut a 1.1.1 tag or 1.2.0 tag from master. This would be the final version of original tf operator. Just for backup purpose.
   v1.1.0...master
   Seems not too many feature changes since 1.1.0. I think 1.1.1 is better than 1.2.0?
   We determine to use 1.2.0 because there're few new features

2. rebase merge all-in-one-operator to master. I cut one for review
   All in one operator rebase merge to master #1320

3. prepare for alpha operator release from master.
   Manifest, test pipelines, etc Universal Operator Phase III: Graduate operator to production grade #1318

What do you think? @kubeflow/wg-training-leads

I am personally ok with any plans. It's fine for us to have more work done in dev branch but it may takes more time and it will also block changes to master (if there's no conflicts, It's ok to merge)

[Jeffwan]

/cc @kubeflow/wg-training-leads

[terrytangyuan]

SGTM.

[johnugeorge]

SGTM.
I will review #1320 in a bit

[gaocegege]

Should we maintain a branch for it?

[Jeffwan]

Should we maintain a branch for it?

That's a good idea. How about rebase all master changes to v1.1-branch? @gaocegege

Seems v1.1-branch was created long time ago to align with Kubeflow release. I think we have two options.

1. I just checked there's no conflicts from master against v1.1-branch. We can use rebase-merge to keep all commit histories
2. Delete the v1.1-branch (not maintained any more) and create a new v1.1-branch from master directly

@gaocegege Please help on that if it sounds good to you.

[Jeffwan]

If we plan to cut a new branch. we don't need to maintain two test pipelines. That save me a lot of time. I will file a PR to enable test and images build for v1.1-branch later once it's created

[gaocegege]

SGTM

[Jeffwan]

1. PR doesn't work because of CLA. Every contributor needs to content it..
2. I can not push upstream v1.1-branch because it's protected. Need googler to help with it. This may take some time, I will move forward and wait for their help at the same time. this is the commit we should create v1.1-branch from 6f1e96c

➜  tf-operator git:(v1.1-branch) ✗ git push -f  upstream v1.1-branch
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote: error: GH006: Protected branch update failed for refs/heads/v1.1-branch.
remote: error: Required status check "cla/google" is failing.
To github.com:kubeflow/tf-operator.git
 ! [remote rejected]   v1.1-branch -> v1.1-branch (protected branch hook declined)
error: failed to push some refs to 'github.com:kubeflow/tf-operator.git'

---

Update: this is not valid anymore. we plan to use v1.2-branch since there're some features inside

[Jeffwan]

Need @Bobgy 's help.

Can you either remove v1.1-branch from protected branch or help create v1.1-branch from 6f1e96c and override the existing one?

/cc @Bobgy

[Bobgy]

My understanding is that, you've got some features changes after v1.1.
By semantic versioning, v1.1.1 should only have bug fixes.

Then following the complexities for merging to v1.1 branch, I think the easiest solution is just to release v1.2 and create a new v1.2-branch. WDUT?

[Jeffwan]

@Bobgy

Sounds good. Let me cut branch v1.2-branch instead and update release. New created branches are not protected and we can handle ourselves. Thanks for the help!

[Jeffwan]

We have cut v1.2-branch to host legacy tensorflow controllers and enable test for any new coming bug fixes.

alpha version of universal training operator has been released https://github.com/kubeflow/tf-operator/releases/tag/v1.3.0-alpha.2.

We can close this issue.