On Tue, Oct 5, 2010 at 6:43 AM, Mark H. Wood <[email protected]> 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 certainly am suggesting keeping around the older docs. I seem to recall
someone out there repeatedly attaching the following quote to all their
email... "Friends don't let friends publish revisable-form documents."
>
> > (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.
>
> The One Location is the wiki, not a particular point in the wiki.
>
> There will never be a time when every DSpace site is running the same
> version. That era ended the day the second DSpace site came online,
> even if it took them a while to diverge.
>
At a certain point there will be little sense to support revisions of older
documentation, thus the point to drop the wiki and reference PDF/HTML files.
I'm not against placing them (PDF) into the distribution as well.
--
Mark R. Diggory
Head of U.S. Operations - @mire
http://www.atmire.com - Institutional Repository Solutions
http://www.togather.eu - Before getting together, get t...@ther
------------------------------------------------------------------------------
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
