Excerpts from Ben Swartzlander's message of 2015-09-08 22:22:38 -0400: > On 09/08/2015 01:58 PM, Doug Hellmann wrote: > > Excerpts from Ben Swartzlander's message of 2015-09-08 13:32:58 -0400: > >> On 09/03/2015 08:22 AM, Thierry Carrez wrote: > >>> Hi everyone, > >>> > >>> A feature deprecation policy is a standard way to communicate and > >>> perform the removal of user-visible behaviors and capabilities. It helps > >>> setting user expectations on how much and how long they can rely on a > >>> feature being present. It gives them reassurance over the timeframe they > >>> have to adapt in such cases. > >>> > >>> In OpenStack we always had a feature deprecation policy that would apply > >>> to "integrated projects", however it was never written down. It was > >>> something like "to remove a feature, you mark it deprecated for n > >>> releases, then you can remove it". > >>> > >>> We don't have an "integrated release" anymore, but having a base > >>> deprecation policy, and knowing which projects are mature enough to > >>> follow it, is a great piece of information to communicate to our users. > >>> > >>> That's why the next-tags workgroup at the Technical Committee has been > >>> working to propose such a base policy as a 'tag' that project teams can > >>> opt to apply to their projects when they agree to apply it to one of > >>> their deliverables: > >>> > >>> https://review.openstack.org/#/c/207467/ > >>> > >>> Before going through the last stage of this, we want to survey existing > >>> projects to see which deprecation policy they currently follow, and > >>> verify that our proposed base deprecation policy makes sense. The goal > >>> is not to dictate something new from the top, it's to reflect what's > >>> generally already applied on the field. > >>> > >>> In particular, the current proposal says: > >>> > >>> "At the very minimum the feature [...] should be marked deprecated (and > >>> still be supported) in the next two coordinated end-of-cyle releases. > >>> For example, a feature deprecated during the M development cycle should > >>> still appear in the M and N releases and cannot be removed before the > >>> beginning of the O development cycle." > >>> > >>> That would be a n+2 deprecation policy. Some suggested that this is too > >>> far-reaching, and that a n+1 deprecation policy (feature deprecated > >>> during the M development cycle can't be removed before the start of the > >>> N cycle) would better reflect what's being currently done. Or that > >>> config options (which are user-visible things) should have n+1 as long > >>> as the underlying feature (or behavior) is not removed. > >>> > >>> Please let us know what makes the most sense. In particular between the > >>> 3 options (but feel free to suggest something else): > >>> > >>> 1. n+2 overall > >>> 2. n+2 for features and capabilities, n+1 for config options > >>> 3. n+1 overall > >> I think any discussion of a deprecation policy needs to be combined with > >> a discussion about LTS (long term support) releases. Real customers (not > >> devops users -- people who pay money for support) can't deal with > >> upgrades every 6 months. > >> > >> Unavoidably, distros are going to want to support certain releases for > >> longer than the normal upstream support window so they can satisfy the > >> needs of the aforementioned customers. This will be true whether the > >> deprecation policy is N+1, N+2, or N+3. > >> > >> It makes sense for the community to define LTS releases and coordinate > >> making sure all the relevant projects are mutually compatible at that > >> release point. Then the job of actually maintaining the LTS release can > >> fall on people who care about such things. The major benefit to solving > >> the LTS problem, though, is that deprecation will get a lot less painful > >> because you could assume upgrades to be one release at a time or > >> skipping directly from one LTS to the next, and you can reduce your > >> upgrade test matrix accordingly. > > How is this fundamentally different from what we do now with stable > > releases, aside from involving a longer period of time? > > 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. Doug > > As sdague mentions, the idea of LTS is really a separate goal from the > deprecation policy, but I see the two becoming related when the > deprecation policy makes it impossible to cleanly jump 4 releases in a > single upgrade. I also believe that if you solve the LTS problem, the > deprecation policy flows naturally from whatever your supported-upgrade > path is: you simply avoid breaking anyone who does a supported upgrade. > > It sounds to me like the current supported upgrade path is: you upgrade > each release one at a time, never skipping over a release. In this > model, N+1 deprecation makes perfect sense. I think the same people who > want longer deprecation periods are the ones who want to skip over > releases when upgrade for the reasons I mention. > > -Ben > > * I'm the kind that never upgrades. I don't fix things that aren't > broken. Until recently I was running FreeBSD 7 and Ubuntu 8.04. > Eventually I was forced to upgrade though when support was dropped. I'm > *still* running CentOS 5 though. > > > Doug > > > >> -Ben Swartzlander > >> > >>> Thanks in advance for your input. > >>> > > __________________________________________________________________________ > > 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 > __________________________________________________________________________ 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