For what it's worth, I agree with you about versioned docs, but we surely have to talk about the technical details.
You are assuming that .htaccess files are taken into consideration by the webserver, which isn't neccessarily so. Most of the httpds out there don't, the Apache httpd being the only one as far as I know. And even the Apache httpd does not necessarily obey the directives of the .htaccess files. As a result, relying on the .htaccess files would "condemn" every mirror (if existing) and mojo.codehaus.org to use the Apache httpd from now on, not to mention a certain configuration of the apache which had to be obeyed (and documented, tested, maintained, *mumble* ...) That beeing said, we could think of creating a site with multiple versions of itself in case according tags are present in the used SCM system. But to be honest with you, I have a strong feeling that this would easily lead to configuration monsters. Propably the easiest way to achieve what you want is to simply add a version number to every "release site" directory and link them manually. Another idea would be to have a directory structure like foo-plugin-site/ |-- 1.0 |-- 1.1 |-- 1.2 `-- 1.3 on the server and have the site-plugin write an index.html according to the existing directories, probably with the help of a meta file in 'foo-plugin-site'. But even the concept would have a major impact on the whole community (since it has an impact on a well introduced behavior) and therefor has to be _carefully_ planned and discussed. Kind regards, Markus Am 22.05.2011 um 01:38 schrieb Benson Margulies: > Something tells me that you've all considered and rejected this before, but > ... > > What if the site deployment URL was set to include a version number > element, and then part of the release process was to update a > .htaccess to point to the latest release? > > Then you could deploy a snapshot site, and people who really wanted to > could look at old release sites, and a new release wouldn't occupy the > main URL until after the vote passed. > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
