It was a little fuzzy because removal of field doesn't necessarily remove the functionality. I went with normal deprecation policy of 1 major rev because it does entail a significant operational cost to be paid (which should motivate you to jump to cachekey anyway). Also in terms of sequence of operations I wanted to have the issue open first so I could have the mailing list discussion and deprecation notice PR linked into the issue so someday a developer is empowered to actually do the work.
Jonathan G On 1/31/19, 10:30 AM, "Rawlin Peters" <[email protected]> wrote: Good point, Chris. I think deprecation notices should be placed in CHANGELOG.md. As a project we need to start getting better at updating the changelog with any significant changes that have been made (including deprecation notices), because it should really be the project's main entrypoint for anyone wanting to know what's changed and should link to more detailed information in the docs where needed. That said, it looks like Jonathan already added this deprecation notice to CHANGELOG.md. Thanks, Jonathan! - Rawlin On Thu, Jan 31, 2019 at 9:13 AM Chris Lemmons <[email protected]> wrote: > > > I'm also going to declare this to be the deprecation notice in 3.x. > > I don't really object, but do we have a specific spot to put > deprecation notices? Like, in the readme or on the website? Seems like > that would be useful, if we don't. > > On Tue, Jan 29, 2019 at 4:15 PM Gray, Jonathan > <[email protected]> wrote: > > > > Since I haven't heard an objection, I'm going to declare consensus on the removal of this field from the data model. Because the removal of this field would require a significant change to delivery services rooted in older versions of ATS which use it, I'm also going to declare this to be the deprecation notice in 3.x. > > > > Jonathan Gray > > > > > > On 1/22/19, 8:31 AM, "Gray, Jonathan" <[email protected]> wrote: > > > > If a deprecation notice would be needed, that's ok. I would assume regardless there would need to be consensus first. Then I can add this email thread to the ticket so we remember down the road. > > > > Jonathan G > > > > > > On 1/18/19, 1:41 PM, "Rawlin Peters" <[email protected]> wrote: > > > > +1. The raw remap line sounds like a reasonable workaround for people > > still on ATS 6. That said, stuff like this typically requires a > > deprecation notice before removal. > > > > - Rawlin > > > > On Fri, Jan 18, 2019 at 10:58 AM Fieck, Brennan > > <[email protected]> wrote: > > > > > > +a million on not supporting a product that has reached it's EOL > > > (definitely not biased to set a precedent for Python 2) > > > ________________________________________ > > > From: Gray, Jonathan <[email protected]> > > > Sent: Wednesday, January 16, 2019 9:42 AM > > > To: [email protected] > > > Subject: [EXTERNAL] Removal of CacheURL DS Field from ATC > > > > > > Hello all, > > > > > > I’d like to get consensus on https://github.com/apache/trafficcontrol/issues/3225 . If we remove the CacheURL delivery service field, you can still use ATS 6 if you must, you’ll just have to use the raw remap text field by hand instead of leaning on TO to generate the config for you. That said, if you’re still on ATS 6 and are doing that, you’re better off upgrading to the more powerful cachekey plugin instead that is supported in ATS 6 and beyond. As ATC supports newer versions of ATS, this is creating extra cruft for new users to stumble across and learn about the hard way not to do. > > > > > > Jonathan G > > > > > > > >
