On Mon, 6 Apr 2020 at 14:46, Sean McGinnis <sean.mcginnis@gmx.com> wrote:
On 4/6/20 8:20 AM, Mark Goddard wrote:
On Mon, 6 Apr 2020 at 13:50, Herve Beraud <hberaud@redhat.com> wrote:
Hello ironic team,
Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Ussuri cycle:
- bifrost - ironic-prometheus-exporter - ironic-ui
Those should be released ASAP, and in all cases before R-3 week (RC1 deadline Apr 20 - Apr 24) , so that we have a release to include in the final Ussuri release. Can we please move to the cycle-with-optional-intermediary release model? I realise it doesn't exist. We (ironic) would like the option to release features outside the normal cadence of the OpenStack release cycle, without being forced to do it. It would save a lot of time, and avoid emails and autogenerated patches each cycle.
I don't have a strong opinion on the Ironic top-level OpenDev project discussion, but I think this is one example of where the team sees unnecessary inflexibility in OpenStack's processes. Perhaps I'm missing something.
Mark
The "independent" release model is basically a cycle-with-optional-intermediary release model, or at least it can be used that way.
If there is nothing to be released for an entire cycle, then that deliverable really isn't cycle based. If the last release from the last cycle is still relevant to the next release, you don't do another release and you just keep using the old, existing release.
So that would be my first suggestion. The other option that Thierry pointed out:
"As swift has proven in the past, you can totally have a product strategy with the cycle-with-intermediary model. You can even maintain your own extra branches (think stable/2.0) if you want. The only extra limitations AFAIK in the integrated release are that (1) you also maintain stable branches at openstack common release points (like stable/train), and (2) that the openstack release management team has an opportunity to check the release numbering for semver sanity."
The benefit of sticking with the cycle based model and making sure at least one release is done per cycle is that we can catch hidden bit rot that gets introduced and causes errors during the release process. This happens, sadly, more often than you might expect.
Sticking with a cycle based model, it can either be cycle-with-intermediary, where we just want to make sure we get some updates along the way, or cycle-with-rc, where we at least always make sure there is a final release at the end of the cycle that picks up any changes. Additional beta releases can be done during the cycle if needed to test and validate changes before everyone is in the freeze at the end.
The important thing is being able to communicate to downstream packagers and other consumers what to expect with these deliverables. If something is "cycle-*" based, but then we don't release anything, that makes it look like that deliverable got dropped. At least if we communicate it is "independent" then this would look normal and packagers know to just keep using that last version.
If it is just an occasional thing that a package doesn't end up with any meaningful updates (I would be kind of suprised, even with low activity deliverables. There are always at least the usual cycle goal and other updates), then it is possible to tag a new version number on the same commit. This isn't great, but it allows us to test out the release process and make sure that is all working. And it allows a new point on which to branch, so should the need ever arise in the future, bug fixes can be backported to distinct branch points for each cycle that needs it.
So we really don't want to introduce a release model that says "we follow the development cycle, maybe we'll release something this cycle, maybe we won't". That would be confusing and introduce uncertainty downstream.
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.
Sean