When I add a regular test-> deploy (after #47) we will be making regular releases. I want to propose the following release and versioning strategy.
We don't match versions of flux-k8s with flux-sched. It adds complexity that I don't think is needed, and often we will have changes here (and no changes to flux-sched) or vice versa. The source of truth will be the version we checkout/build in our Dockerfile/Makefile.
Each week we will do one build to test the current scheduler-plugins upstream against here. A successful set of builds should release the latest tag for each container, along with a YYYY-MM-DD tag. I've seen no issue with GitHub having many tags so I think this will work ok to deploy 52/year (registries share layers, so there will be redundancy there).
We do explicit releases just via traditional GitHub release, and that will trigger the workflow here to build a container with the same release number. I propose that after #47 is merged, we create release 0.1.0 of fluence and then can increment however others like (I'm weird and change the patch version typically, but I'm good to go with what others like).
In summary:
latest and YYYY-MM-DD will be updated weekly, with fresh builds against upstream scheduler-plugins
latest and x.x.x will be done manually when we decide to do releases
The versions can increment as we like, with no forced frequency and under our jurisdiction to decide when to bump patch vs. minor vs. major.
When I add a regular test-> deploy (after #47) we will be making regular releases. I want to propose the following release and versioning strategy.
latesttag for each container, along with aYYYY-MM-DDtag. I've seen no issue with GitHub having many tags so I think this will work ok to deploy 52/year (registries share layers, so there will be redundancy there).In summary:
latestandYYYY-MM-DDwill be updated weekly, with fresh builds against upstream scheduler-pluginslatestandx.x.xwill be done manually when we decide to do releases