[ironic][release] List cycle-with-intermediary deliverables that have not been released yet
sean.mcginnis at gmx.com
Mon Apr 6 18:28:38 UTC 2020
>>> 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.
>> 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
More information about the openstack-discuss