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.
-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
