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 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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
