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 <[email protected]>
Sent: Wednesday, January 9, 2019 10:52 AM
To: [email protected]
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" <[email protected]> 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 <[email protected]>
Sent: Wednesday, January 9, 2019 10:03 AM
To: [email protected]
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 <[email protected]> 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 <[email protected]>
> 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" <[email protected]> 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 <
> [email protected]>
> > wrote:
> > >
> > > makes perfect sense to me
> > >
> > > On Tue, Jan 8, 2019 at 2:42 PM Fieck, Brennan <
> > [email protected]>
> > > 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.
> > > >
> > > >
> >
> >
> >
>
