Hi Mark W, Comments inline...
On 10/5/2010 8:43 AM, Mark H. Wood wrote: > In general I think the proposed progression is a good model. > > On Mon, Oct 04, 2010 at 02:38:40PM -0700, Mark Diggory wrote: > [quoting Tim Donohue] >>> (3) After 1.7, and once we are ready to start docs for a 1.8.0 release, >>> we'll copy the "DSDOC" space into a "DSDOC1.7" wiki space as an archive >>> (and as necessary to support any future 1.7.x releases), and the "DSDOC" >>> area would move towards 1.8.0 docs. At this point, there may be some >>> double wiki changes required if a single Documentation change needs >>> fixing in both 1.7.x and the 1.8.x documentation (since they will sit >>> separately in the Wiki). >>> >> >> I think this gets quickly becomes too complex. Recommend static publication >> of docs a release time that does not change, pointer to the latest bleeding >> edge docs in wiki if folks want to add read about whats new. As described >> above. > > *sigh* Sometimes folks want to read about what's *old*. As in: the > version I am running, not some latest version that I haven't installed > yet. Or this older version that lost its admin. a year ago and now > I've been asked to bring it up-to-date. > > Heh, we still have a heavily customized 1.4+Manakin installation, > because it has not yet become urgent enough to upgrade it. That will > happen, but not today. > > And those old versions need maintenance, corrected documentation, etc. > We need the doco. for a previous release to remain live until the > changes slow to the point that we can settle for a live errata > section plus the mummified main body. > > Old software versions *never go away*; they only become less popular. I think you do have a good point here (and I also talked through this with others in DuraSpace to get their views on this discussion). It's a tough balance here, as there are benefits of both keeping everything in one "space" (less confusion around where changes can/should be made) and also copying off to a second "wiki space" (to enable old docs to receive updates if necessary). Maybe what we should really think about is a "initial trial period" with a compromise setup. So, once we get around to 1.8.0, we can "archive" a copy of the current DSpace Docs into a *read-only* wiki space (named 'DSDOC1.7' or similar). All 1.8 documentation work would still occur back in the DSDOC main space (as we have already discussed in this thread). But, we'd also have a read-only, archived copy of the 1.7.x wiki docs *just in case* we find we need them. Therefore, if we found we absolutely needed to update the 1.7.x Documentation and regenerate the HTML/PDF (because of some glaring, serious error), we could. But, hopefully we'd find it wasn't necessary (in which case that 'DSDOC1.7' space would remain 'read-only' until we decided it was time to delete it altogether.) Maybe that is a decent compromise to these two competing scenarios? I should mention that copying a space into a 'read-only' archive is very easy to do in Confluence -- so, that will take minimal effort to achieve. - Tim ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
