Isn't point of independent release to eliminate need of such backports? As you are should be just able to use newest/latest release for caracal as well? I believe no. IIUC the point was to eliminate need of stable branch maintenance which is redundant for stable components.
In general independent release model makes it difficult to pull bug fixes to stable branches, because once any breaking change or new feature is introduced in master then we no longer able to bump versions in stable branch u-c. For example we will remove python 3.8 support during this cycle, so once we get a new release with python 3.8 support removal then we may no longer able to bump stable constraints. Some of the oslo's deliverables such as oslo.messaging was switched back to cycle model after we faced such situations. Creating a bug fix release may work or this specific case, but my concern is that we may face problems in case we get some more bugs reported in the future, and we have more such risks nowadays after a few active development cycles. On 5/8/24 20:36, Dmitriy Rabotyagov wrote:
Um, I'm slightly confused.
Isn't point of independent release to eliminate need of such backports? As you are should be just able to use newest/latest release for caracal as well?
So maybe it's matter of just bumping tooz version in upper-constraints for caracal rather than changing the release model?
As according to the bug report and patch for it - I don't see why we would want to change release model, rather then build/package new version of tooz for caracal.
On Wed, May 8, 2024, 08:54 Takashi Kajinami <kajinamit@oss.nttdata.com <mailto:kajinamit@oss.nttdata.com>> wrote:
Hello,
As you may know, tooz was moved to the independent release model[1] after wallaby release because of its stable code base at that time.
However, we introduced several features/improvements in tooz during a few cycles and I'm wondering if we can revisit its status now. One actual problem I'm seeing now is that, we recently got a bug report[2] about the redis sentinel support which we added during 2024.1 cycle but we can't backport the required bug fix to 2024.1 because of no stable branch.
Given the situation, I'm wondering if it makes sense (and is possible) to move tooz back to the cycle-with-intermediary model, and create 2024.1 branch from 6.1.0 (the last release during 2024.1 cycle) now, so that we can maintain 2024.1 releases with future bug fixes brackported.
[1] https://review.opendev.org/c/openstack/releases/+/788230 <https://review.opendev.org/c/openstack/releases/+/788230> [2] https://bugs.launchpad.net/python-tooz/+bug/2063857 <https://bugs.launchpad.net/python-tooz/+bug/2063857>
-- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit <https://github.com/kajinamit> launchpad: https://launchpad.net/~kajinamit <https://launchpad.net/~kajinamit>