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
