On Mon, 2020-04-06 at 13:28 -0500, Sean McGinnis wrote:
Thanks for the detailed response Sean. I don't have an issue with the cycle model - Ironic is still tied to the cyclical release model. The part that I disagree with is the requirement to create an intermediary release. It shouldn't be a problem if bifrost doesn't make a feature release between Train and Ussuri, we'll just do a final Ussuri release. It's the intermediary I'd like to be optional, rather than the final cycle release. for what its worth i was suprised with the requirement to make more then one release with the cycle-with-intermediary cycle too. i orginally tought when os-vif moved to it we could make intermediat release if we wanted too not that we were required to make them at each milestone.
looking at the text https://github.com/openstack/releases/blob/35595343ddba5db598a80ce9238df28f2... The "cycle-with-intermediary" model describes projects that produce multiple full releases during the development cycle, with a final release to match the end of the cycle. "cycle-with-intermediary" projects commit to produce a release near the end of the 6-month development cycle to be used with projects using the other cycle-based release models that are required to produce a release at that time. Release tags for deliverables using this tag are reviewed and applied by the Release Management team. im not actully sure where that requirem of 1 relase per miles stone came from but we were told to do it by the release team so we do. releaes are relitvely cheap so its not a burden to do this but as we did between m2 and non clinet lib freeze we often have period where we dont need to do a release yet or we would prefer to wait for a patch to merge which we expect to merge a few days out after a milestone and its has been annoying to have to release a milestone release under the cycle-with-intermediary release model in those cases. if there was a corss poject depency i have just asked for a release a day or two later when the patch i was waiting for merged if waited to the next milestoen if it was an internal fix. its also possible that the reqirements for a release at each milestone was misscomunicated for cycle-with-intermediary but since it has happened at 2 or 3 times i now just assume its required even if its not documented as such.
I would suggest switching these to cycle-with-rc then. There is one release candidate that has to happen just before the final release for the cycle, but that's mainly to make sure everything is in good shape before we declare it done. That sounds like it might fit better with what the team wants to do here.
But what if we want to create a feature release mid-cycle? Some cycles we do, some we don't.
With cycle-with-rc, that does allow *beta* releases to be done at any point during the cycle. But those would be marked as b1, b2, etc. releases. This allows those that want to try out upcoming features to grab them if they want them, but would prevent anyone else from accidentally picking up something before it is quite ready.
I'm guessing this might not be what you are looking for though.
We do have another release model called cycle-automatic. This was introduced for tempest plugins to just do a release at the end of the cycle to make sure there is a tag to denote the tempest version the plugin was originally developed for. Since some plugins are being picked up more often downstream, this model does allow for additional releases to be proposed at any point during the development cycle.
We will need to discuss this as a team to see if this makes sense for non-tempest plugins. It was intended only for those types of deliverables. I just mention it here as something that we do have in place that might be adapted to fit what the team needs. But we also need to consider what we are communicating to downstream consumers of our releases, so I'm not entirely sure at this point if it makes sense, or would be a good thing, to allow other types of deliverables to use this model.
Sean