[TASK] Define first release artifacts and branches for notebooks-v1

[andyatmiami]

Certification

• I certify I am an Epic Owner for Kubeflow Notebooks 2.0 and expected to create planning-related issues.

Description

Before creating the first release for the notebooks-v1 branch, we need to ensure that we are aligned on a couple of details that can affect future releases as well.

Specifically, before the first release we'll need to make sure we've agreed on:

• What image names should we use for the migrated components?
• What branching strategy should we use for cutting releases?
• Which docker tag should we use for the first release?
  The above will be quite important to agree on before the release, as it will dictate the future releases as well.

cc @juliusvonkohout @thesuperzapper @kimwnasptd

Acceptance Criteria

• Consensus reached (explicitly or via lazy consensus) on image names for notebooks-v1
• Consensus reached (explicitly or via lazy consensus) on branching strategy for notebooks-v1
• Consensus reached (explicitly or via lazy consensus) on docker tags for notebooks-v1

[andyatmiami]

My proposed plan is the following:

Image names

The main changes is simply publishing to ghcr.io/kubeflow/notebooks (whereas originally it was ghcr.io/kubeflow/kubeflow)

• ghcr.io/kubeflow/notebooks/notebook-controller
• ghcr.io/kubeflow/notebooks/tensorboard-controller
• ghcr.io/kubeflow/notebooks/pvcviewer-controller
• ghcr.io/kubeflow/notebooks/jupyter-web-app
• ghcr.io/kubeflow/notebooks/tensorboards-web-app
• ghcr.io/kubeflow/notebooks/volumes-web-app

Branching strategy

I'd keep the same branching policy as we used to do with kubeflow/kubeflow were we had vX.Y.Z tags and vX.Y-branch branches.

Which tag to use

As we don't plan any significant changes to notebooks-v1 moving forward (with focus being on notebooks-v2) - I feel like continuing with the current Kubeflow tagging is appropriate.

1. v1.11.0 image tag
2. v1.11-branch

[andyatmiami]

/area v1