Managing project documentation (release vs CVS versions) ?
Hi, I have always been pondering how to best manage the following. Should there be 2 web sites per project : one for the latest release (containing docs + javadoc corresponding to the latest release) and one for nightly builds (containing docs + javadocs corresponding to the latest code) ? When I work on a new feature that I want to document, I cannot document it in the xdocs/ directory because next time I change something for the web site and I want to make that change visible, it will also contain the new feature documentation. However, that feature is only present in CVS (not released yet) and users will have trouble understanding why this feature does not work with the code they downloaded. Of course, I could have a header that says WARNING: Feature only available in CVS but it is awkward. Another solution is to have 2 xdocs directory but again this is awkward ... Any idea ? How are other projects doing this ? Thanks -Vincent ___ Vincent Massol OCTO Technology UK Ltd www.octo.com [EMAIL PROTECTED] Tel: (020) 8996 9540 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Managing project documentation (release vs CVS versions) ?
The recomended solution for this is to use a branch. ie When you make a release you also branch at same instant. Then if you need to update the current web docs you modify them in the branch, then update the website (which is using last branch released). If you need to update the docs for the current CVS then you do it in the main trunk/HEAD revision. When needed you merge the branch back into the main trunk. However I don't know of any projects that do this except for ant. It may also require a bit more CVS savvy that normal but should be possible to do if that is what cactus/whatever needs. On Thu, 17 Jan 2002 10:34, Vincent Massol wrote: Hi, I have always been pondering how to best manage the following. Should there be 2 web sites per project : one for the latest release (containing docs + javadoc corresponding to the latest release) and one for nightly builds (containing docs + javadocs corresponding to the latest code) ? When I work on a new feature that I want to document, I cannot document it in the xdocs/ directory because next time I change something for the web site and I want to make that change visible, it will also contain the new feature documentation. However, that feature is only present in CVS (not released yet) and users will have trouble understanding why this feature does not work with the code they downloaded. Of course, I could have a header that says WARNING: Feature only available in CVS but it is awkward. Another solution is to have 2 xdocs directory but again this is awkward ... Any idea ? How are other projects doing this ? Thanks -Vincent ___ Vincent Massol OCTO Technology UK Ltd www.octo.com [EMAIL PROTECTED] Tel: (020) 8996 9540 -- Cheers, Pete *--* | Nearly all men can stand adversity, but if you want | | to test a man's character, give him power. | | -Abraham Lincoln | *--* -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Managing project documentation (release vs CVS versions) ?
I should have thought about this ... stupid me ... Thanks. -Vincent -Original Message- From: Peter Donald [mailto:[EMAIL PROTECTED]] Sent: 16 January 2002 23:38 To: Jakarta General List Subject: Re: Managing project documentation (release vs CVS versions) ? The recomended solution for this is to use a branch. ie When you make a release you also branch at same instant. Then if you need to update the current web docs you modify them in the branch, then update the website (which is using last branch released). If you need to update the docs for the current CVS then you do it in the main trunk/HEAD revision. When needed you merge the branch back into the main trunk. However I don't know of any projects that do this except for ant. It may also require a bit more CVS savvy that normal but should be possible to do if that is what cactus/whatever needs. On Thu, 17 Jan 2002 10:34, Vincent Massol wrote: Hi, I have always been pondering how to best manage the following. Should there be 2 web sites per project : one for the latest release (containing docs + javadoc corresponding to the latest release) and one for nightly builds (containing docs + javadocs corresponding to the latest code) ? When I work on a new feature that I want to document, I cannot document it in the xdocs/ directory because next time I change something for the web site and I want to make that change visible, it will also contain the new feature documentation. However, that feature is only present in CVS (not released yet) and users will have trouble understanding why this feature does not work with the code they downloaded. Of course, I could have a header that says WARNING: Feature only available in CVS but it is awkward. Another solution is to have 2 xdocs directory but again this is awkward ... Any idea ? How are other projects doing this ? Thanks -Vincent ___ Vincent Massol OCTO Technology UK Ltd www.octo.com [EMAIL PROTECTED] Tel: (020) 8996 9540 -- Cheers, Pete *--* | Nearly all men can stand adversity, but if you want | | to test a man's character, give him power. | | -Abraham Lincoln | *--* -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Managing project documentation (release vs CVS versions) ?
You don't have to use a branch - just check out with the release tag. It is sticky and will not get updated by cvs update. Conor -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED]] Sent: Thursday, 17 January 2002 10:45 AM To: 'Jakarta General List' Subject: RE: Managing project documentation (release vs CVS versions) ? I should have thought about this ... stupid me ... Thanks. -Vincent -Original Message- From: Peter Donald [mailto:[EMAIL PROTECTED]] Sent: 16 January 2002 23:38 To: Jakarta General List Subject: Re: Managing project documentation (release vs CVS versions) ? The recomended solution for this is to use a branch. ie When you make a release you also branch at same instant. Then if you need to update the current web docs you modify them in the branch, then update the website (which is using last branch released). If you need to update the docs for the current CVS then you do it in the main trunk/HEAD revision. When needed you merge the branch back into the main trunk. However I don't know of any projects that do this except for ant. It may also require a bit more CVS savvy that normal but should be possible to do if that is what cactus/whatever needs. On Thu, 17 Jan 2002 10:34, Vincent Massol wrote: Hi, I have always been pondering how to best manage the following. Should there be 2 web sites per project : one for the latest release (containing docs + javadoc corresponding to the latest release) and one for nightly builds (containing docs + javadocs corresponding to the latest code) ? When I work on a new feature that I want to document, I cannot document it in the xdocs/ directory because next time I change something for the web site and I want to make that change visible, it will also contain the new feature documentation. However, that feature is only present in CVS (not released yet) and users will have trouble understanding why this feature does not work with the code they downloaded. Of course, I could have a header that says WARNING: Feature only available in CVS but it is awkward. Another solution is to have 2 xdocs directory but again this is awkward ... Any idea ? How are other projects doing this ? Thanks -Vincent ___ Vincent Massol OCTO Technology UK Ltd www.octo.com [EMAIL PROTECTED] Tel: (020) 8996 9540 -- Cheers, Pete *--* | Nearly all men can stand adversity, but if you want | | to test a man's character, give him power. | | -Abraham Lincoln | *--* -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
