nt: 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
ev@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 wrote:
om: Dave Neuman
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, 201
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 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 vers
+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
wrote:
> I would consider keeping a footnote somewhere that outlines any upgrade
> seque
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. Th
+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 w
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
wrote:
> makes perfect sense to me
>
> On Tue, Jan 8, 2019 at 2:42 PM Fieck, Brennan
> wrote:
>
> > Can anybody think of a reason why the ATC 3.x docs should include the
makes perfect sense to me
On Tue, Jan 8, 2019 at 2:42 PM Fieck, Brennan
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 -
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 m
10 matches
Mail list logo
