On 5/8/24 22:26, Jeremy Stanley wrote:
On 2024-05-08 21:23:25 +0900 (+0900), Takashi Kajinami wrote: [...]
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. [...]
I think the original intent was to keep such libraries compatible with all maintained stable branches. If you run some stable branch jobs from the oldest currently maintained branch on all proposed changes, that can act as insurance against accidentally breaking things. This is the approach which, e.g., PBR takes, though in that case we try to keep it compatible with unmaintained branches too since it's basically impossible to pin.
I'm not too sure if that was the original intention at least for oslo, given the fact that all independent deliverables have been using the latest python job template, and drops support for old python versions once removed from master. We can technically try this approach, but longer life cycle of unmaintained branches is making the overall maintenance quite difficult. I'd rather prefer restoring stable branch concept here, which we've done for the other oslo repos.