A few quick inline comments... On 10/4/2010 4:38 PM, Mark Diggory wrote: > As for future versioning -- we really need to formalize this based on > what we all feel is best. One possible option may be as follows: > > (1) "DSDOC" space > (https://wiki.duraspace.org/display/DSDOC/DSpace+Documentation) -- this > would be the place were we are *always* working on the latest & greatest > documentation. It could also act as a "splash page" to find all past > DSpace release documentation. So, currently this is working towards > 1.7.0 documentation. We should also be working to "clean up" the front > page and all sub-pages to our liking for 1.7 (It may still need quite a > bit of work.) > > (2) When 1.7.0 is released, we can export an HTML or PDF version of that > documentation directly from the "DSDOC" area. We could even put this > into SVN if we wished, or just make it downloadable alongside the > release. > > > I'm all for a readme with an http link to a version specific page in the > Docs wiki. It would contain links to the static html version, pdf > version and a link describing where to make suggestions for corrections, > recommendations and/or additions.
Nice idea. That'd be fine by me as well. > (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. Yea -- I can see your point. The main counter-example I could think of was if we happened to be simultaneously working on a 1.7.x bug fix release while also doing a 1.8.0 release. In that sort of situation, where you are doing simultaneous releases of different versions, you'd want your documentation kept separate somehow. But, maybe we just cross that bridge if we ever come to it (so far, we've never really done a simultaneous release like that -- so, I'm probably making this too complex! :). Your idea, Mark, is easier (so, we'd just do #1 and #2 as I had listed, and NOT #3 nor #4). Simple is probably best for now. If we ever needed to expand to something more complex we could do so later on. > (4) Eventually (i.e. years from now) in order to avoid keeping around > tons of old wiki spaces (e.g. DSDOC1.7, DSDOC1.8, DSDOC1.9, DSDOC2.0, > etc) for really old documentation, we'll want to clean up old "archived" > wiki documentation. So, once a space becomes "dormant" or "static", we > can just archive a final version to HTML/PDF and post that static > version up on the DSpace website. Then we can remove that old, dormant > wiki space altogether. > > > My concern is that this creates the overhead you talk about above, > rather than getting everyone "rallying" around one location for changes > to docs. > > This is just one possible idea for how to handle things. So, if there > are other thoughts on upcoming management of Wiki Documentation after > 1.7, we can definitely add that to an upcoming meeting agenda as needed. > > Thoughts/ideas welcome, > > > Thanks, Tim, for the great summarization on the topic. > > Mark > - Tim ------------------------------------------------------------------------------ Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
