You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by "Fieck, Brennan" <Br...@comcast.com> on 2019/01/08 21:41:58 UTC
Removing old migration instructions
Can anybody think of a reason why the ATC 3.x docs should include the pages for migrating from 1.x to 2.x or from 2.0 to 2.2? IMO the docs for version X.y should include instructions that pertain to version X - so an upgrade from X-1 to X would be fine, but from X-1.y to X-1.y+z doesn't really make sense.
To be clear, I'm suggesting the removal of
https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/migration_from_10_to_20.html
and
https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/migration_from_20_to_22.html
from the latest (3.x) docs.
Re: Removing old migration instructions
Posted by Dave Neuman <ne...@apache.org>.
Submit a PR to remove them. Anything < 2.2 is not officially supported
anyway.
On Tue, Jan 8, 2019 at 2:56 PM Jeremy Mitchell <mi...@gmail.com>
wrote:
> makes perfect sense to me
>
> On Tue, Jan 8, 2019 at 2:42 PM Fieck, Brennan <Br...@comcast.com>
> wrote:
>
> > Can anybody think of a reason why the ATC 3.x docs should include the
> > pages for migrating from 1.x to 2.x or from 2.0 to 2.2? IMO the docs for
> > version X.y should include instructions that pertain to version X - so an
> > upgrade from X-1 to X would be fine, but from X-1.y to X-1.y+z doesn't
> > really make sense.
> >
> > To be clear, I'm suggesting the removal of
> >
> >
> >
> https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/migration_from_10_to_20.html
> > and
> >
> >
> >
> https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/migration_from_20_to_22.html
> >
> >
> > from the latest (3.x) docs.
> >
> >
>
Re: [EXTERNAL] Re: Removing old migration instructions
Posted by "Fieck, Brennan" <Br...@comcast.com>.
To sort of wrap this up, this kind of order of operations would be best documented in the same place where an upgrade procedure from 2.x -> 3.x is documented. Currently we don't have that; is there anything special that needs to be done beyond `yum update traffic_{{component}}`? If so, anybody feel like writing it up? I'd be happy to convert it to RST if someone knows the steps but doesn't want to write docs.
________________________________________
From: Gray, Jonathan <Jo...@comcast.com>
Sent: Wednesday, January 9, 2019 10:52 AM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL] Re: Removing old migration instructions
I'm not suggesting keeping around the 2.1.0 RTD. Just a simple string that lists the sequence you have to upgrade through. Even if it's just as simple as `1.x -> 2.x -> 3.x`; that's ok. That would tell you not to go directly from `1.x -> 3.x`. If you have to use it, you'll probably have to checkout the repo and figure out the docs yourself just like you'll probably have to compile it yourself.
Jonathan G
On 1/9/19, 10:24 AM, "Fieck, Brennan" <Br...@comcast.com> wrote:
I'm with Dave on this.
I don't even know if a link to the old docs would be helpful; they're pretty garbled because the custom CSS was being improperly imported, take a look: https://traffic-control-cdn.readthedocs.io/en/release-2.1.0/
________________________________________
From: Dave Neuman <ne...@apache.org>
Sent: Wednesday, January 9, 2019 10:03 AM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL] Re: Removing old migration instructions
I disagree, we don't support many of our old versions and we don't even
provide the release on our release page.
On Wed, Jan 9, 2019 at 9:40 AM Robert Butts <ro...@apache.org> wrote:
> +1 on a footnote. Otherwise, it's going to be a pain for someone to dig
> through every version of the docs to upgrade an old version.
>
> Links would be even better.
>
> On Tue, Jan 8, 2019 at 8:18 PM Gray, Jonathan <Jo...@comcast.com>
> wrote:
>
> > I would consider keeping a footnote somewhere that outlines any upgrade
> > sequence requirements such as 1.0 -> 1.12 -> 2.0 -> 2.21 -> 3.0. Mostly
> > just so that if you do find yourself inheriting an antique setup that
> must
> > be maintained in place you know how many hops you should be looking for.
> > That said, agreed that old docs can live in old builds in general.
> >
> > Jonathan G
> >
> >
> > On 1/8/19, 4:58 PM, "Rawlin Peters" <ra...@gmail.com> wrote:
> >
> > +1, old docs will always be available in the old releases if they
> > still need to be referenced. In general I think that should be a
> > documentation guideline for the project, so that whenever we cut a
> > release branch we can (and should) freely remove documentation from
> > master that does not pertain to whatever the next release is going to
> > be.
> >
> > - Rawlin
> >
> > On Tue, Jan 8, 2019 at 2:56 PM Jeremy Mitchell <
> mitchell852@gmail.com>
> > wrote:
> > >
> > > makes perfect sense to me
> > >
> > > On Tue, Jan 8, 2019 at 2:42 PM Fieck, Brennan <
> > Brennan_Fieck@comcast.com>
> > > wrote:
> > >
> > > > Can anybody think of a reason why the ATC 3.x docs should include
> > the
> > > > pages for migrating from 1.x to 2.x or from 2.0 to 2.2? IMO the
> > docs for
> > > > version X.y should include instructions that pertain to version X
> > - so an
> > > > upgrade from X-1 to X would be fine, but from X-1.y to X-1.y+z
> > doesn't
> > > > really make sense.
> > > >
> > > > To be clear, I'm suggesting the removal of
> > > >
> > > >
> > > >
> >
> https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/migration_from_10_to_20.html
> > > > and
> > > >
> > > >
> > > >
> >
> https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/migration_from_20_to_22.html
> > > >
> > > >
> > > > from the latest (3.x) docs.
> > > >
> > > >
> >
> >
> >
>
Re: [EXTERNAL] Re: Removing old migration instructions
Posted by "Gray, Jonathan" <Jo...@comcast.com>.
I'm not suggesting keeping around the 2.1.0 RTD. Just a simple string that lists the sequence you have to upgrade through. Even if it's just as simple as `1.x -> 2.x -> 3.x`; that's ok. That would tell you not to go directly from `1.x -> 3.x`. If you have to use it, you'll probably have to checkout the repo and figure out the docs yourself just like you'll probably have to compile it yourself.
Jonathan G
On 1/9/19, 10:24 AM, "Fieck, Brennan" <Br...@comcast.com> wrote:
I'm with Dave on this.
I don't even know if a link to the old docs would be helpful; they're pretty garbled because the custom CSS was being improperly imported, take a look: https://traffic-control-cdn.readthedocs.io/en/release-2.1.0/
________________________________________
From: Dave Neuman <ne...@apache.org>
Sent: Wednesday, January 9, 2019 10:03 AM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL] Re: Removing old migration instructions
I disagree, we don't support many of our old versions and we don't even
provide the release on our release page.
On Wed, Jan 9, 2019 at 9:40 AM Robert Butts <ro...@apache.org> wrote:
> +1 on a footnote. Otherwise, it's going to be a pain for someone to dig
> through every version of the docs to upgrade an old version.
>
> Links would be even better.
>
> On Tue, Jan 8, 2019 at 8:18 PM Gray, Jonathan <Jo...@comcast.com>
> wrote:
>
> > I would consider keeping a footnote somewhere that outlines any upgrade
> > sequence requirements such as 1.0 -> 1.12 -> 2.0 -> 2.21 -> 3.0. Mostly
> > just so that if you do find yourself inheriting an antique setup that
> must
> > be maintained in place you know how many hops you should be looking for.
> > That said, agreed that old docs can live in old builds in general.
> >
> > Jonathan G
> >
> >
> > On 1/8/19, 4:58 PM, "Rawlin Peters" <ra...@gmail.com> wrote:
> >
> > +1, old docs will always be available in the old releases if they
> > still need to be referenced. In general I think that should be a
> > documentation guideline for the project, so that whenever we cut a
> > release branch we can (and should) freely remove documentation from
> > master that does not pertain to whatever the next release is going to
> > be.
> >
> > - Rawlin
> >
> > On Tue, Jan 8, 2019 at 2:56 PM Jeremy Mitchell <
> mitchell852@gmail.com>
> > wrote:
> > >
> > > makes perfect sense to me
> > >
> > > On Tue, Jan 8, 2019 at 2:42 PM Fieck, Brennan <
> > Brennan_Fieck@comcast.com>
> > > wrote:
> > >
> > > > Can anybody think of a reason why the ATC 3.x docs should include
> > the
> > > > pages for migrating from 1.x to 2.x or from 2.0 to 2.2? IMO the
> > docs for
> > > > version X.y should include instructions that pertain to version X
> > - so an
> > > > upgrade from X-1 to X would be fine, but from X-1.y to X-1.y+z
> > doesn't
> > > > really make sense.
> > > >
> > > > To be clear, I'm suggesting the removal of
> > > >
> > > >
> > > >
> >
> https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/migration_from_10_to_20.html
> > > > and
> > > >
> > > >
> > > >
> >
> https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/migration_from_20_to_22.html
> > > >
> > > >
> > > > from the latest (3.x) docs.
> > > >
> > > >
> >
> >
> >
>
Re: [EXTERNAL] Re: Removing old migration instructions
Posted by "Fieck, Brennan" <Br...@comcast.com>.
I'm with Dave on this.
I don't even know if a link to the old docs would be helpful; they're pretty garbled because the custom CSS was being improperly imported, take a look: https://traffic-control-cdn.readthedocs.io/en/release-2.1.0/
________________________________________
From: Dave Neuman <ne...@apache.org>
Sent: Wednesday, January 9, 2019 10:03 AM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL] Re: Removing old migration instructions
I disagree, we don't support many of our old versions and we don't even
provide the release on our release page.
On Wed, Jan 9, 2019 at 9:40 AM Robert Butts <ro...@apache.org> wrote:
> +1 on a footnote. Otherwise, it's going to be a pain for someone to dig
> through every version of the docs to upgrade an old version.
>
> Links would be even better.
>
> On Tue, Jan 8, 2019 at 8:18 PM Gray, Jonathan <Jo...@comcast.com>
> wrote:
>
> > I would consider keeping a footnote somewhere that outlines any upgrade
> > sequence requirements such as 1.0 -> 1.12 -> 2.0 -> 2.21 -> 3.0. Mostly
> > just so that if you do find yourself inheriting an antique setup that
> must
> > be maintained in place you know how many hops you should be looking for.
> > That said, agreed that old docs can live in old builds in general.
> >
> > Jonathan G
> >
> >
> > On 1/8/19, 4:58 PM, "Rawlin Peters" <ra...@gmail.com> wrote:
> >
> > +1, old docs will always be available in the old releases if they
> > still need to be referenced. In general I think that should be a
> > documentation guideline for the project, so that whenever we cut a
> > release branch we can (and should) freely remove documentation from
> > master that does not pertain to whatever the next release is going to
> > be.
> >
> > - Rawlin
> >
> > On Tue, Jan 8, 2019 at 2:56 PM Jeremy Mitchell <
> mitchell852@gmail.com>
> > wrote:
> > >
> > > makes perfect sense to me
> > >
> > > On Tue, Jan 8, 2019 at 2:42 PM Fieck, Brennan <
> > Brennan_Fieck@comcast.com>
> > > wrote:
> > >
> > > > Can anybody think of a reason why the ATC 3.x docs should include
> > the
> > > > pages for migrating from 1.x to 2.x or from 2.0 to 2.2? IMO the
> > docs for
> > > > version X.y should include instructions that pertain to version X
> > - so an
> > > > upgrade from X-1 to X would be fine, but from X-1.y to X-1.y+z
> > doesn't
> > > > really make sense.
> > > >
> > > > To be clear, I'm suggesting the removal of
> > > >
> > > >
> > > >
> >
> https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/migration_from_10_to_20.html
> > > > and
> > > >
> > > >
> > > >
> >
> https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/migration_from_20_to_22.html
> > > >
> > > >
> > > > from the latest (3.x) docs.
> > > >
> > > >
> >
> >
> >
>
Re: [EXTERNAL] Re: Removing old migration instructions
Posted by Dave Neuman <ne...@apache.org>.
I disagree, we don't support many of our old versions and we don't even
provide the release on our release page.
On Wed, Jan 9, 2019 at 9:40 AM Robert Butts <ro...@apache.org> wrote:
> +1 on a footnote. Otherwise, it's going to be a pain for someone to dig
> through every version of the docs to upgrade an old version.
>
> Links would be even better.
>
> On Tue, Jan 8, 2019 at 8:18 PM Gray, Jonathan <Jo...@comcast.com>
> wrote:
>
> > I would consider keeping a footnote somewhere that outlines any upgrade
> > sequence requirements such as 1.0 -> 1.12 -> 2.0 -> 2.21 -> 3.0. Mostly
> > just so that if you do find yourself inheriting an antique setup that
> must
> > be maintained in place you know how many hops you should be looking for.
> > That said, agreed that old docs can live in old builds in general.
> >
> > Jonathan G
> >
> >
> > On 1/8/19, 4:58 PM, "Rawlin Peters" <ra...@gmail.com> wrote:
> >
> > +1, old docs will always be available in the old releases if they
> > still need to be referenced. In general I think that should be a
> > documentation guideline for the project, so that whenever we cut a
> > release branch we can (and should) freely remove documentation from
> > master that does not pertain to whatever the next release is going to
> > be.
> >
> > - Rawlin
> >
> > On Tue, Jan 8, 2019 at 2:56 PM Jeremy Mitchell <
> mitchell852@gmail.com>
> > wrote:
> > >
> > > makes perfect sense to me
> > >
> > > On Tue, Jan 8, 2019 at 2:42 PM Fieck, Brennan <
> > Brennan_Fieck@comcast.com>
> > > wrote:
> > >
> > > > Can anybody think of a reason why the ATC 3.x docs should include
> > the
> > > > pages for migrating from 1.x to 2.x or from 2.0 to 2.2? IMO the
> > docs for
> > > > version X.y should include instructions that pertain to version X
> > - so an
> > > > upgrade from X-1 to X would be fine, but from X-1.y to X-1.y+z
> > doesn't
> > > > really make sense.
> > > >
> > > > To be clear, I'm suggesting the removal of
> > > >
> > > >
> > > >
> >
> https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/migration_from_10_to_20.html
> > > > and
> > > >
> > > >
> > > >
> >
> https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/migration_from_20_to_22.html
> > > >
> > > >
> > > > from the latest (3.x) docs.
> > > >
> > > >
> >
> >
> >
>
Re: [EXTERNAL] Re: Removing old migration instructions
Posted by Robert Butts <ro...@apache.org>.
+1 on a footnote. Otherwise, it's going to be a pain for someone to dig
through every version of the docs to upgrade an old version.
Links would be even better.
On Tue, Jan 8, 2019 at 8:18 PM Gray, Jonathan <Jo...@comcast.com>
wrote:
> I would consider keeping a footnote somewhere that outlines any upgrade
> sequence requirements such as 1.0 -> 1.12 -> 2.0 -> 2.21 -> 3.0. Mostly
> just so that if you do find yourself inheriting an antique setup that must
> be maintained in place you know how many hops you should be looking for.
> That said, agreed that old docs can live in old builds in general.
>
> Jonathan G
>
>
> On 1/8/19, 4:58 PM, "Rawlin Peters" <ra...@gmail.com> wrote:
>
> +1, old docs will always be available in the old releases if they
> still need to be referenced. In general I think that should be a
> documentation guideline for the project, so that whenever we cut a
> release branch we can (and should) freely remove documentation from
> master that does not pertain to whatever the next release is going to
> be.
>
> - Rawlin
>
> On Tue, Jan 8, 2019 at 2:56 PM Jeremy Mitchell <mi...@gmail.com>
> wrote:
> >
> > makes perfect sense to me
> >
> > On Tue, Jan 8, 2019 at 2:42 PM Fieck, Brennan <
> Brennan_Fieck@comcast.com>
> > wrote:
> >
> > > Can anybody think of a reason why the ATC 3.x docs should include
> the
> > > pages for migrating from 1.x to 2.x or from 2.0 to 2.2? IMO the
> docs for
> > > version X.y should include instructions that pertain to version X
> - so an
> > > upgrade from X-1 to X would be fine, but from X-1.y to X-1.y+z
> doesn't
> > > really make sense.
> > >
> > > To be clear, I'm suggesting the removal of
> > >
> > >
> > >
> https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/migration_from_10_to_20.html
> > > and
> > >
> > >
> > >
> https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/migration_from_20_to_22.html
> > >
> > >
> > > from the latest (3.x) docs.
> > >
> > >
>
>
>
Re: [EXTERNAL] Re: Removing old migration instructions
Posted by "Gray, Jonathan" <Jo...@comcast.com>.
I would consider keeping a footnote somewhere that outlines any upgrade sequence requirements such as 1.0 -> 1.12 -> 2.0 -> 2.21 -> 3.0. Mostly just so that if you do find yourself inheriting an antique setup that must be maintained in place you know how many hops you should be looking for. That said, agreed that old docs can live in old builds in general.
Jonathan G
On 1/8/19, 4:58 PM, "Rawlin Peters" <ra...@gmail.com> wrote:
+1, old docs will always be available in the old releases if they
still need to be referenced. In general I think that should be a
documentation guideline for the project, so that whenever we cut a
release branch we can (and should) freely remove documentation from
master that does not pertain to whatever the next release is going to
be.
- Rawlin
On Tue, Jan 8, 2019 at 2:56 PM Jeremy Mitchell <mi...@gmail.com> wrote:
>
> makes perfect sense to me
>
> On Tue, Jan 8, 2019 at 2:42 PM Fieck, Brennan <Br...@comcast.com>
> wrote:
>
> > Can anybody think of a reason why the ATC 3.x docs should include the
> > pages for migrating from 1.x to 2.x or from 2.0 to 2.2? IMO the docs for
> > version X.y should include instructions that pertain to version X - so an
> > upgrade from X-1 to X would be fine, but from X-1.y to X-1.y+z doesn't
> > really make sense.
> >
> > To be clear, I'm suggesting the removal of
> >
> >
> > https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/migration_from_10_to_20.html
> > and
> >
> >
> > https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/migration_from_20_to_22.html
> >
> >
> > from the latest (3.x) docs.
> >
> >
Re: Removing old migration instructions
Posted by Rawlin Peters <ra...@gmail.com>.
+1, old docs will always be available in the old releases if they
still need to be referenced. In general I think that should be a
documentation guideline for the project, so that whenever we cut a
release branch we can (and should) freely remove documentation from
master that does not pertain to whatever the next release is going to
be.
- Rawlin
On Tue, Jan 8, 2019 at 2:56 PM Jeremy Mitchell <mi...@gmail.com> wrote:
>
> makes perfect sense to me
>
> On Tue, Jan 8, 2019 at 2:42 PM Fieck, Brennan <Br...@comcast.com>
> wrote:
>
> > Can anybody think of a reason why the ATC 3.x docs should include the
> > pages for migrating from 1.x to 2.x or from 2.0 to 2.2? IMO the docs for
> > version X.y should include instructions that pertain to version X - so an
> > upgrade from X-1 to X would be fine, but from X-1.y to X-1.y+z doesn't
> > really make sense.
> >
> > To be clear, I'm suggesting the removal of
> >
> >
> > https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/migration_from_10_to_20.html
> > and
> >
> >
> > https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/migration_from_20_to_22.html
> >
> >
> > from the latest (3.x) docs.
> >
> >
Re: Removing old migration instructions
Posted by Jeremy Mitchell <mi...@gmail.com>.
makes perfect sense to me
On Tue, Jan 8, 2019 at 2:42 PM Fieck, Brennan <Br...@comcast.com>
wrote:
> Can anybody think of a reason why the ATC 3.x docs should include the
> pages for migrating from 1.x to 2.x or from 2.0 to 2.2? IMO the docs for
> version X.y should include instructions that pertain to version X - so an
> upgrade from X-1 to X would be fine, but from X-1.y to X-1.y+z doesn't
> really make sense.
>
> To be clear, I'm suggesting the removal of
>
>
> https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/migration_from_10_to_20.html
> and
>
>
> https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/migration_from_20_to_22.html
>
>
> from the latest (3.x) docs.
>
>