Define Release process for sriov-network-operator

[adrianchiris]

sriov-network-operator deploys several sub-components which are either managed in project or in external project (but still managed within npwg). We should define a release process for the project so that it clear what components are intended to be deployed by the user for a certain release.

Sriov network operator currently deploys the following components:

1. sriov network operator (in project)
2. sriov network config daemon (in project)
3. sriov network operator webhook (in project, optional)
4. sriov network device plugin (external)
5. sriov cni (external)
6. ib sriov cni (external)
7. network resource injector (external)

When doing a release it is desirable to have a tagged version of each component which we recommend to use and deploy by default in helm.

we should have an issue template for new release which will depict all the needed steps. as our CI and day to day work usually uses the latest components(containers) from external projects, it makes sense, when sriov-network-operator is released, to use these versions. that way we can be sure that we release a "bundle" which was tested. if an external project wasnt changed (no commits) between sriov-network-operator releases then it is not required to do a release for that project.

A release flow could consist of:

1. Create release issue in all external project (target what we want in that release depending on the time-frame)
2. Create release issue in sriov-network operator project (target what we want in that release depending on the time-frame)
3. for each external project: do release according to each project guidelines (tag version, build containers, update release notes, update README, yamls etc)
4. release network operator (tag version, build containers, update release notes with information on the versions of the external components, update README, yamls etc)
5. Create a new chart with the released version in npwg helm char repo in its own subdir (named sriov-network-operator-X.Y.Z, X.Y.Z being the version)
6. Upload the helm package (tgz) to sriov-network-operator as release artifact

later on we could consider managing our own helm repo (or npwg help repo ?) with sriov-network-operator charts.

[zshi-redhat]

later on we could consider managing our own helm repo (or npwg help repo ?) with sriov-network-operator charts.

@adrianchiris What is our own helm repo? Is it the helm chats in sriov-network-operator repo?

[adrianchiris]

@adrianchiris What is our own helm repo? Is it the helm chats in sriov-network-operator repo?

essentially have a place where we host the charts and you can access them via helm repo command one way of doing that is with github pages in the project.