Open kimwnasptd opened 11 months ago
Not a blocker but something to consider - we maintain a test suite that has shared code across multiple versions (to reduce the effort of actually maintaining it). For example, test code for 1.7 is reused for 1.8, etc. If we adopted branches as proposed, some possible ways forward are:
Also it isn't that using branches removes the need to have copies of our testing code and different bundles, it just bookkeeps them differently (the copies are in branches, not in main). Not saying branches are better or worse, just saying its a bookkeeping change rather than removing something entirely
I don't think our other repos function exactly as described in the original post. Our charm repos:
track
branches in our repos represent the code currently in trackX/edge
Its a bit of a hybrid, and I dont know if its clear what the analagous organisation would be for the bundle kubeflow repo. Maybe each release has a branch, but then that branch has the current version of all four risks rather than just edge?
What needs to get done
Like the rest of the Charm repos, I propose that we should have dedicated branches for releases in this repo.
Why it needs to get done
Having a flat architecture means that we'll need to create release folders for everything. This results in
On the other had if we'd use branches then the structure of this repo would be hugely simplified and different branches would just contain the code that is needed (and dependency versions like microk8s, juju) in each branch.
Items we need to consider though for this work are: