Open Stack

Anne Bertucio wrote:
> How many past versions we support is a balance between upstream 
> community effort required and creating a user/operator-friendly project. 
> Per Tim’s example on the Arch call, the average K8s user is not on the 
> most current release, and in OpenStack the average user is typically 
> N-2. While we want to encourage them to upgrade, it’s just not the 
> operator reality.
> 
> In Vancouver, the game plan on release cadence was to switch to 
> time-based releases for major and minor (x.0.0 and 1.y.0 respectively) 
> as soon as we felt it was feasible. We agreed to lean on the Arch 
> Committee to guide us to when that would be. I feel like having a handle 
> on what our time-based cadence might be will help in evaluating the 
> “upstream community effort required” piece of the puzzle. Any thoughts 
> since Vancouver on what our cadence might look like?

A bit of generic advice from my experience doing release management on 
several openly-developed open source projects:

Main release cadence is a trade-off between getting features out and the 
cost of releasing/upgrading/maintaining. On the "more often" side, you 
generally find developers wanting fast feedback on their development 
(release early, release often) and users waiting for a specific feature 
(especially in the early days of a project). On the "less often" side, 
you generally find people impacted by the action of releasing (release 
managers when releases are not fully automated, marketing teams doing 
communications), existing users needing to upgrade (when upgrade is not 
trivial) and stable release maintainers (more releases meaning more 
backporting work).

If you manage to limit the release cost (by automating release 
management and limiting marketing release communications), reduce the 
upgrade cost (by making it dead easy to upgrade, skip versions or 
support multiple versions running alongside), then the only thing 
preventing you from releasing very often is the stable release maintenance.

Stable release maintenance is a bit tricky, as in a lot of cases (like 
Kubernetes or OpenStack) deployers are years behind, and maintaining all 
branches for all releases leading up to that is painful (you basically 
have to backport bugfixes for all supported branches, and community 
volunteers for that job are not plenty). It also impacts automated 
testing, as you sometimes need to keep a lot of test nodes around to 
test those old branches. If you support upgrading from any version to 
any version, you can solve some of that using a LTS scheme. But if users 
have to go through every version to upgrade, the solution is to keep a 
relatively long release cadence and only support a handful of past branches.

Now, I feel like Kata may have a unique profile here (due to where it 
runs and how it's upgraded) which may well support a rather aggressive 
cadence. Would it support upgrade from any version to any version ? 
Would you upgrade running containers, or just let the old version run 
alongside the new version ?

Hoping this helps,

-- 
Thierry Carrez (ttx)