----- "Rich Bowen" <[email protected]> wrote: > Assuming that we can make it work with the various rewrite rules and > stuff, here's what I'd like to see: > > /docs/ still goes to /docs/1.3/ for the short term. We update those > docs to provide links to the improved resource. Later down the road (6 > months? a year?) we start providing distinct 1.3 vs latest links on > those pages, and then eventually move /docs/ to point to > /docs/current/ > > /docs/x.y/ goes to docs/x.y/ Duh > > /docs/current goes to /docs/2.2 and gets updated with each subsequent > release. > > 404 goes to a helpful page explaining that the 1.3 version is > abandonware, and here's a link to a redirection thingy that might know > what you were looking for. > > The downside is that we don't get seamless redirection for 1.3 links > (although we might in some cases) and so existing broken links remain > broken until someone takes the initiative to fix them. I'm not > persuaded by the "don't break links" argument. A good link to a bad > resource is a broken link, by definition. > > After some further discussion on IRC, I suppose I'll say what I really > think. > > > Having /docs/ redirect to /docs/1.3/ no longer makes sense. /docs/1.3/ > should be a permanent redirect to /docs/current/ which should be a 302 > to /docs/2.2 (or whatever is current at the time).
This doesn't make sense. /docs/1.3/ should stay where it is. I suppose you mean /docs/ -> /docs/current/ > We'll need to have some sensible handling of 404 conditions. A nice > 404 handler with multiple choices would be great. But the time has > passed to be serving 1.3 docs as our default response for /docs/ > requests. > > > I'm going to send Tony a patch to make this happen. I think that the > time has come. > > > > > -- > Rich Bowen > [email protected] -- Igor Galić Tel: +43 (0) 699 122 96 338 Fax: +43(0) 1 91 333 41 Mail: [email protected] URL: http://brainsware.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
