[openstack-dev] [all] Base feature deprecation policy

Robert Collins robertc at robertcollins.net
Wed Sep 9 22:22:36 UTC 2015


On 10 September 2015 at 06:18, Doug Hellmann <doug at 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 <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud



More information about the OpenStack-dev mailing list