On 10 September 2015 at 06:18, Doug Hellmann <d...@doughellmann.com> wrote: > Excerpts from Ben Swartzlander's message of 2015-09-08 22:22:38 -0400:
>> It would be a recognition that most customers don't want to upgrade >> every 6 months -- they want to skip over 3 releases and upgrade every 2 >> years. I'm sure there are customers all over the spectrum from those who >> run master to those to do want a new release every 6 month, to some that >> want to install something and run it forever without upgrading*. My >> intuition is that, for most customers, 2 years is a reasonable amount of >> time to run a release before upgrading. I think major Linux distros >> understand this, as is evidenced by their release and support patterns. > > As Jeremy pointed out, we have quite a bit of trouble now maintaining > stable branches. given that, it just doesn't seem realistic in this > community right now to expect support for a 2 year long LTS period. > Given that, I see no real reason to base other policies around the > idea that we might do it in the future. If we *do* end up finding > more interest in stable/LTS support, then we can revisit the > deprecation period at that point. Also, there's a number of things that are bundled up into the one thing today: - schema migrations - cross-version compatibility (or lack thereof) of deps [and co-installability too] - RPC compatibility - config file compatibility All of which impact the ability to do rolling upgrades. Non-rolling upgrades without config changes are a bit of a special case, but also important. So any LTS discussion needs to cover: - resourcing the maintenance of the LTS branch - solving the technical problems in keeping the branch running as the platform it was developed on ages underneath it - solving the technical problems in dealing with libraries that are moving on while its staying static (and please no, do not suggest LTS branches for oslo libraries - they are only a subset of the problem) - dealing with having compat code hang around in-tree for much longer So the backwards compatibility aspect of this discussion is really just the tip of the iceberg. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev