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