commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [ALL] fix site doc version so it agrees with release [was: [compress] Two issues with releasing the release]
Date Fri, 22 May 2009 23:01:21 GMT
On 22/05/2009, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> On Fri, May 22, 2009 at 9:14 AM, sebb <sebbaz@gmail.com> wrote:
>  > On 22/05/2009, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
>  >> On Fri, May 22, 2009 at 7:08 AM, sebb <sebbaz@gmail.com> wrote:
>  >>  > On 22/05/2009, Christian Grobmeier <grobmeier@gmail.com> wrote:
>  >>  >> > Another minor glitch I noticed just now. All pages seem to include
a
>  >>  >>  > green "1.1-SNAPSHOT" in the grey headline, which may come in
via the
>  >>  >>  > generating style sheet or an ant property (I didn't check how
the site
>  >>  >>  > is generated).
>  >>  >>
>  >>  >>
>  >>  >> Thanks, but it looks like "know issue":
>  >>  >>
>  >>  >>  http://wiki.apache.org/commons/CreatingReleases :
>  >>  >>
>  >>  >>  "E.3 Deploy the Site
>  >>  >>
>  >>  >>  Run mvn site-deploy to deploy the site - please note that you are
>  >>  >>  deploying the site of the next development snapshot. "
>  >>  >
>  >>  > That's awful - surely there has to be a better way to do this?
>  >>  >
>  >>  > Would it work if the site-deploy was run from a checkout of the release
tag?
>  >>  >
>  >>
>  >> <snip/>
>  >>
>  >>  Yes, but often, there is value to having latest docs online as well,
>  >>  and pointers to docs for more than one release. My SOP is:
>  >>
>  >>  a) On release, checkout tag, deploy site
>  >>  b) Move docs (Javadocs, perhaps a user guide) to a release area
>  >>  c) Checkout trunk, add nav menu to release area, deploy site
>  >>  d) Maintain last few (3?) rolling release areas
>  >>
>  >
>  > OK, but it seems to me that the main documentation should relate to
>  > the current release; past or future documentation can be made
>  > available as well, but it is critical that the current documentation
>  > is readily available. (*)
>  >
>  > Are there any examples/documentation to show exactly how this is done?
>  >
>
> <snip/>
>
>  No docs, just the list in the email above :-) You can look at the
>  [SCXML] or [digester] site to get some idea of what was done. Adjust
>  recipe per taste.

The above mentioned sites go part-way towards solving the problem, in
that the Javadoc, releases notes and source are available for multiple
releases, however the "Project Reports" section only relates to one
version, and in the case of SCXML the Javadoc sub-section is actually
for 0.10 rather than 0.90. Note that the header on the site is
0.10-SNAPSHOT; looks like the site was generated incorrectly.

Digester has 2.1-SNAPSHOT in the header although the current release
is 2.0, so presumably the common "Project Reports" and "Project Info"
sections relate to 2.1-SNAPSHOT.

I'm afraid neither of those are satisfactory in my opinion.

However, it must be possible to do it, because BeanUtils (for example)
shows the same version in the header as the current release, and also
has documentation for two earlier releases.

>
>  -Rahul
>
>
>
>  > (*) In the case of Compress, the 1.1-SNAPSHOT docs are (currently) the
>  > same as 1.0, but how is the user to know that?
>  >
>
>
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message