+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. > > > > > > > > >
