The problem I'm seeing with deploying the side as needed is, that the JavaDoc report will the so latest trunk and not the latest released API. In [LANG] we have the link to the latest realese JavaDoc. Compress for example has no such link. So a redeploy (for example to add some more documentation) will override the JavaDoc report. This may confuse users. In other words: if the site build and deploy is decoupled from releases, there should be a link to the JavaDoc of the latest release.
Benedikt 2013/10/13 Henri Yandell <flame...@gmail.com> > On Sun, Oct 13, 2013 at 11:03 AM, Luc Maisonobe <luc.maison...@free.fr > >wrote: > > > Le 13/10/2013 17:35, Stefan Bodewig a écrit : > > > Hi all > > > > > > in the recent release vote for Compress Gary and I had very different > > > opinions on the importance of the site build for release candidates. > > > > > > On 2013-10-13, Gary Gregory wrote: > > > > > >> On Sun, Oct 13, 2013 at 1:31 AM, Stefan Bodewig <bode...@apache.org> > > wrote: > > > > > >>> I have not created a RC website as the only difference to the current > > >>> website would be the download page and the version number - and I'd > > >>> immediately change the site after the release to include the release > > >>> date anyway. > > > > > >> - Using the live site for the RC is a bad idea IMO because the source > > >> will have to be changed to update the version, for example "The > > >> current release is 1.5." and "Commons Compress 1.5 requires Java 5" > > >> and who knows what else will have to be changed. This means that what > > >> is in the RC is NOT building the 1.6 site, it is building a SNAPSHOT > > >> site. > > > > > > To me creating the site is one of the completely unnecessary steps to > > > perform when cutting a release candidate. Building and uploading the > > > site takes something > 15 minutes to me. So far I have never published > > > the RC site when the RC was accepted but rather created a new site > build > > > that contained the release date, updated the changes report with a > > > placeholder for the next release and so on. > > > > > > We can - and should - update the site outside of any release anyway, so > > > to me the site content is completely irrelevant when I evaluate > > > releases. > > > > > > I'll admit that this mirrors my suspicion that nobody looks at the site > > > build contained in the binary release anyway. People use their > > > dependency manager of choice and the online docs in my experience. > > > > > > How do others think about the release candidate site build? > > > > I agree the site build is orthogonal to release. > > The main thing we release is source code. Then on top of that we add > > some binaries, but it is already a by-product. The site itself is not > > something we should consider to be in the scope of the release. > > > > > Agreed - the site build as a whole is for informative purposes during a > vote. If there are any bugs in a site, they never block the release as they > can be fixed out of band. > > The only items that should be blockers on the site build are those included > in the distribution. I thought that was only the javadoc instead of the > whole site? I'd definitely consider a bad javadoc to be something we should > consider a new RC for, though it would depend on the severity. The cost of > building a new RC is greater than fixing a typo in javadoc. > > Hen > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
