Site Builds and Release Votes
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? Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Site Builds and Release Votes
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. Luc Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Site Builds and Release Votes
On Sun, Oct 13, 2013 at 11:03 AM, Luc Maisonobe luc.maison...@free.frwrote: 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
Re: Site Builds and Release Votes
On 10/13/13 11:51 AM, Henri Yandell wrote: On Sun, Oct 13, 2013 at 11:03 AM, Luc Maisonobe luc.maison...@free.frwrote: 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. +1 - though I think we should be carefully reviewing the javadoc in prep for releases and evaluation of RCs. The other exception to this rule is when components ship user guides. These should be updated for releases and should be evaluated as part of RC evaluation. But I agree strongly with the view that updating the public site can and should be viewed as a post-release activity. I also don't think we should be shipping full site contents in binary releases if somehow we have reverted to doing that. The xdoc/apt/whatever should be tagged and included as part of source release, but nits with it should not be release blockers, IMO. Phil Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Site Builds and Release Votes
Am 13.10.2013 20:51, schrieb Henri Yandell: On Sun, Oct 13, 2013 at 11:03 AM, Luc Maisonobe luc.maison...@free.frwrote: 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 But shouldn't the site at least be in sync with a new release regarding stuff like descriptions of new features, updated user guides, etc.? It is part of the release process to deploy the site. So it should not be too much additional effort to prepare this for an RC. I remember that in past we also had problems with sites that were updated during development. Then we received bug reports because features advertised in the documentation were not available in the released version. So I cannot agree to the statement that a site update can be done at any time. Oliver - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Site Builds and Release Votes
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
Re: Site Builds and Release Votes
On 13 October 2013 20:26, Benedikt Ritter brit...@apache.org wrote: 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. +1 I think the site should reflect the current release(s). That does not mean it cannot be updated post-release, e.g. to correct errors / improve the documentation. But it's very confusing to have a site that contains documentation for code that has not been released. What we do on the JMeter project is to create an SVN branch for the documentation. Any necessary changes are applied to the branch (and trunk if relevant) and the site regenerated from the branch. 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
