[ironic][release] List cycle-with-intermediary deliverables that have not been released yet

Sean McGinnis sean.mcginnis at gmx.com
Mon Apr 6 13:45:52 UTC 2020


On 4/6/20 8:20 AM, Mark Goddard wrote:
> On Mon, 6 Apr 2020 at 13:50, Herve Beraud <hberaud at 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.

Sean




More information about the openstack-discuss mailing list