You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Needing dedicated GH action files (publish, run uats etc) for different releases
Copies of the testing code
Copies of the different bundles
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:
The release handbook with manual steps on when to create the branches
Which docs would we need to update
Any files that are hardcoding file paths that require release folders
The text was updated successfully, but these errors were encountered:
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:
backport changes to relevant branches
moving any common testing code into a separate, generic repo, and importing it as a dependency here
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
Charmhub releases (which we document with corresponding releases in our gh repos) represent everything in beta/candidate/stable.
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:
The text was updated successfully, but these errors were encountered: