Em 04.11.2015 11:32, Jim Rollenhagen escreveu:
On Wed, Nov 04, 2015 at 08:44:36AM -0500, Jay Pipes wrote:
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.
Right, so I asked Gabriel to send this because it's an odd case, and
I'd
like to clear up the governance doc on this, since it doesn't seem to
say much about code that was never released.
The rule is a cycle boundary *and* at least 3 months. However, in this
case, the code was never in a release at all, much less a stable
release. So looking at the two types of deployers:
1) CD from trunk: 3 months is fine, we do that, done.
2) Deploying stable releases: if we only wait three months and not a
cycle boundary, they'll never see it. If we do wait for a cycle
boundary, we're pushing deprecated code to them for (seemingly to me)
no
benefit.
So, it makes sense to me to not introduce the cycle boundary thing in
this case. But there is value in keeping the rule simple, and if we
want
this one to pass a cycle boundary to optimize for that, I'm okay with
that too. :)
(Side note: there's actually a third type of deployer for Ironic; one
that deploys intermediate releases. I think if we give them at least
one
release and three months, they're okay, so the general standard
deprecation rule covers them.)
// jim
So, summarizing that:
* untagged/master: 3 months
* tagged/intermediate release: max(next tag/intermediate release, 3
months)
* stable release: max(next release, 3 months)
Is it correct?
__________________________________________________________________________
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
