On 11/03/2015 11:40 PM, Gabriel Bezerra wrote:
Hi,
The change in https://review.openstack.org/237122 touches a feature from
ironic that has not been released in any tag yet.
At first, we from the team who has written the patch thought that, as it
has not been part of any release, we could do backwards incompatible
changes on that part of the code. As it turned out from discussing with
the community, ironic commits to keeping the master branch backwards
compatible and a deprecation process is needed in that case.
That stated, the question at hand is: How long should this deprecation
process last?
This spec specifies the deprecation policy we should follow:
https://github.com/openstack/governance/blob/master/reference/tags/assert_follows-standard-deprecation.rst
As from its excerpt below, the minimum obsolescence period must be
max(next_release, 3 months).
"""
Based on that data, an obsolescence date will be set. At the very
minimum the feature (or API, or configuration option) should be marked
deprecated (and still be supported) in the next stable release branch,
and for at least three months linear time. For example, a feature
deprecated in November 2015 should still appear in the Mitaka release
and stable/mitaka stable branch and cannot be removed before the
beginning of the N development cycle in April 2016. A feature deprecated
in March 2016 should still appear in the Mitaka release and
stable/mitaka stable branch, and cannot be removed before June 2016.
"""
This spec, however, only covers released and/or tagged code.
tl;dr:
How should we proceed regarding code/features/configs/APIs that have not
even been tagged yet?
Isn't waiting for the next OpenStack release in this case too long?
Otherwise, we are going to have features/configs/APIs/etc. that are
deprecated from their very first tag/release.
How about sticking to min(next_release, 3 months)? Or next_tag? Or 3
months? max(next_tag, 3 months)?
-1
The reason the wording is that way is because lots of people deploy
OpenStack services in a continuous deployment model, from the master
source branches (sometimes minus X number of commits as these deployers
run the code through their test platforms).
Not everyone uses tagged releases, and OpenStack as a community has
committed (pun intended) to serving these continuous deployment scenarios.
Best,
-jay
__________________________________________________________________________
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
