Re: [openstack-dev] [all][ironic] How to proceed about deprecation of untagged code?
On Wed, Nov 04, 2015 at 12:19:37PM -0800, Jim Rollenhagen wrote: [snip] > Yeah, no worries there. So you're good with unreleased changes just > being 3 months, no cycle boundaries? If so, I'll push up a change to the > governance repo for that. That change is here: https://review.openstack.org/#/c/242117/ // jim __ 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
Re: [openstack-dev] [all][ironic] How to proceed about deprecation of untagged code?
Em 04.11.2015 17:19, Jim Rollenhagen escreveu: On Wed, Nov 04, 2015 at 02:55:49PM -0500, Sean Dague wrote: On 11/04/2015 02:42 PM, Jim Rollenhagen wrote: > On Wed, Nov 04, 2015 at 04:08:18PM -0300, Gabriel Bezerra wrote: >> 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? > > No, my proposal is that, but s/max/AND/. > > This also needs buyoff from other folks in the community, and an update > to the document in the governance repo which requires TC approval. > > For now we must assume a cycle boundary and three months, and/or hold off on > the patch until this is decided. The AND version of this seems to respect the spirit of the original intent. The 3 month window was designed to push back a little on last minute deprecations for release, that we deleted the second master landed. Which looked very different for stable release vs. CD consuming folks. The intermediate rel
Re: [openstack-dev] [all][ironic] How to proceed about deprecation of untagged code?
On Wed, Nov 04, 2015 at 02:55:49PM -0500, Sean Dague wrote: > On 11/04/2015 02:42 PM, Jim Rollenhagen wrote: > > On Wed, Nov 04, 2015 at 04:08:18PM -0300, Gabriel Bezerra wrote: > >> 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? > > > > No, my proposal is that, but s/max/AND/. > > > > This also needs buyoff from other folks in the community, and an update > > to the document in the governance repo which requires TC approval. > > > > For now we must assume a cycle boundary and three months, and/or hold off on > > the patch until this is decided. > > The AND version of this seems to respect the spirit of the original > intent. The 3 month window was designed to push back a little on
Re: [openstack-dev] [all][ironic] How to proceed about deprecation of untagged code?
On 11/04/2015 02:42 PM, Jim Rollenhagen wrote: > On Wed, Nov 04, 2015 at 04:08:18PM -0300, Gabriel Bezerra wrote: >> 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? > > No, my proposal is that, but s/max/AND/. > > This also needs buyoff from other folks in the community, and an update > to the document in the governance repo which requires TC approval. > > For now we must assume a cycle boundary and three months, and/or hold off on > the patch until this is decided. The AND version of this seems to respect the spirit of the original intent. The 3 month window was designed to push back a little on last minute deprecations for release, that we deleted the second master landed. Which looked very different for stable release vs. CD consuming folks. The intermediate release or no-release model just wasn't considered initially. -Sean -- Sean Dague http://dague.net
Re: [openstack-dev] [all][ironic] How to proceed about deprecation of untagged code?
On Wed, Nov 04, 2015 at 04:08:18PM -0300, Gabriel Bezerra wrote: > 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? No, my proposal is that, but s/max/AND/. This also needs buyoff from other folks in the community, and an update to the document in the governance repo which requires TC approval. For now we must assume a cycle boundary and three months, and/or hold off on the patch until this is decided. // jim __ 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
Re: [openstack-dev] [all][ironic] How to proceed about deprecation of untagged code?
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
Re: [openstack-dev] [all][ironic] How to proceed about deprecation of untagged code?
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 __ 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
Re: [openstack-dev] [all][ironic] How to proceed about deprecation of untagged code?
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
[openstack-dev] [all][ironic] How to proceed about deprecation of untagged code?
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. __ 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
