I'm still wrapping my head around your proposal... It appears you want to drop the "stable branch" part of the release rather than the regular tagging and tracking of what has been tested together (the "integrated release").
It definitely sounds possible to me to:
- have all components use an intermediary-released model (release as needed, no common feature freeze, no RCs)
- have regular points in time where we communicate combinations of components that work together
- not create stable branches for those components, not backport any bugfix and just roll forward (single branch development)
That’s what I am proposing indeed. I have added the exception that _projects_ can decide to go multi branch, where it makes sense. The TC decides what warrants a branch, to have a common behaviour across the whole openstack (see examples below).
Then you would still have a comparison baseline ("I run X"), and you would still have "openstack releases" that you can communicate and generate excitement around. And it would definitely reduce the backporting work happening upstream.
Correct.
However I am not sure I see how that proposal solves the upgrade pressure, or make downstream distribution work any easier... which are the two major reasons people ask for a longer cycle in the current system. If anything, that would make both worse, no?
1) Small backports don’t have to happen until a big, disruptive, work happens. This relieves a bit of pressure on contributions, and make the contributions more meaningful tbh. (cf. the "oh it wasn't backported to this branch" syndrome ;)).
2) When a new branch is created, the _project_ could decide what to do with the branch. “We will abandon this legacy code in x”. The TC might decide a series of rules of when to close branches (or if it’s even allowed)
3) Downstream distributions would still get maintained software, and in fact it would be easier to understand. e.g. for packagers: The master branch rolls forward, and has regular tags (intermediary-released), all of them are not disruptive for users/packaging. If a project decides to branch (because they brought a very disruptive change), then it could be considered for packagers as creating a “new version” of a package, obsoleting an older package. Very simple for packagers AND users.
4) The result of a strong “let’s never branch” model is that we can have easier upgrades: We can decide that the upgrades between two version of the same branch have to be seemless, while a switch from an older branch to a newer branch must require a “migration” tool in place.
Regards,
Jean-Philippe Evrard (evrardjp)