Open Stack

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)?


Best regards,
Gabriel Bezerra.