Open Stack

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