Well, that raises an interesting problem. When a user goes to the Struts site, they expect to see documentation covering the latest released version, but when developers maintain the site, they are documenting the latest code in development.

I like the idea of automatically versioned sites as part of our release process as it makes it easier for the users. Also, this scheme makes it more obvious which version the material covers. I'm especially in favor of it as long as the unreleased versions are cleared marked with a link to the last stable.

To be clear, the primary Struts site isn't and shouldn't be versioned. This is the code in struts/site. The versioning discussion is regarding the generated site docs from each Struts version.

In summary, I think the solution you propose solves all the issues nicely.

Don

Ted Husted wrote:
On 7/5/06, Don Brown <[EMAIL PROTECTED]> wrote:
I chose 1.x and 2.0 because I think it fits better with the other archived web
sites.  The struts1 and struts2 names are more for internal use and in
particular, struts1 is only used in svn due to the maven workaround. I think 1.x and 2.0, as well as the past 1.2.9 and so on, is easier for the user to
"guess" and remember.

I could see a case for creating such folders to automatically version
the websites. Instead of creating 1.3.5 and 2.0.0 folders later to
host site archives, as we do now,

* http://struts.apache.org/1.2.9/

We could start creating the versioned folders upfront and then
redirecting from struts/1.2 to struts/1.2.9, and so forth.

If we want to do that, then we should setup physical folders for 1.3.5
and 2.0.0 and setup the appropriate redirects for struts/1.3 and
struts/2.0 to the latest versions. Then once each version rolls, we
could create the 1.3.6 and 2.0.1 folders and update the redirects.

In this way, people could link to Struts/1.3 or Struts/2.0 and be
directed to the site for the latest working milestone in the series.

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to