[OPEN-ILS-DOCUMENTATION] work in progress...
Soulliere, Robert
robert.soulliere at mohawkcollege.ca
Thu Sep 16 11:09:27 EDT 2010
Hi Steve,
One important thing to keep in mind is that Each version of Evergreen will have its own set of documentation and one manual.
Currently we are working on 1.6 and including instructions for that version
Eventually, we will work on 2.0 on a separate branch of the repository and a separate manual.
Hopefully we can be similar to the PostgreSQL documentation which allows you to look at documentation for a very specific version of PostgreSQL. See: http://www.postgresql.org/ and look at the links on the right for documentation.
Given that we want to have specific documentation for specific versions of Evergreen, I wonder if a section on upgrading older versions is optimal or necessary? I would try to keep the documentation specific to the version. Offering instructions for installing older versions might cause more confusion. Moreover, I think it is a good idea to encourage installation of the current stable version of Evergreen not older versions. Evergreen 1.4 might be considered a current stable version at this time, but I believe that will change when 2.0 is released I believe.
After more thought, I think it might also be a good idea to have 1.6.1 in its own branch and its own documentation set. I forgot about the differences in installation and upgrading from 1.6.0. The only case where we should merge them is if 1.6.1 would be considered the stable version and 1.6.0 would be relegated to non stable status in short order. I wasn't quite sure about the plan.
Question for developers: Is it a case where we recommend 1.6.1 as an option over 1.6.0 only if the user wants the added features (e.g. booking) or is it the case where 1.6.1 will be the recommended install/upgrade option for anyone considering installing Evergreen or upgrading? If it is the case where 1.6..1 is the recommended option over 1.6.0, then we could combine them in one documentation and perhaps provide alternate instructions for 1.6.0. I do think an important policy is to keep our documentation for 1.6 to issues and items for the 1.6.x series exclusively and not to delve into the "code museum".
Other thought ans insights?
Robert
________________________________________
From: open-ils-documentation-bounces at list.georgialibraries.org [open-ils-documentation-bounces at list.georgialibraries.org] On Behalf Of steve sheppard [ssheps at gmail.com]
Sent: September 16, 2010 10:38 AM
To: open-ils-documentation at list.georgialibraries.org
Subject: [OPEN-ILS-DOCUMENTATION] work in progress...
All,
Just finished up more parts of "Serverside Installation" with the expansion of several subsections.
It has more-or-less been scanned for proper semantic markup, spelling, etc., and is ready for general review.
Also updated the dokuwiki to suit.
Onward to other subsections for installation of PostgreSQL and Apache.
-------------------------------------
Also, maybe this has already been covered?...
They weren't in our initial outline, but since the new versions Evergreen 1.6.1.x and OpenSRF 1.4.x now show up on the "Evergreen Downloads" web page ( http://open-ils.org/cvs.php ), should we add those two versions to the "Server-side Installation" section?
Of course, that begs the larger question: "How should we handle adding the-next-Evergreen-version to our docs?"
I would think that the "Install Current Version" section is always in flux as we modify it to suit the-next-Evergreen-version, and the section "Install Previous Versions" section is then modified by having the *previous* the-next-Evergreen-version prepended to the (growing) list of previous version instructions.
What think you?
Cheers!
--Steve
This E-mail contains privileged and confidential information intended
only for the individual or entity named in the message. If the reader
of this message is not the intended recipient, or the agent responsible
to deliver it to the intended recipient, you are hereby notified that
any review, dissemination, distribution or copying of this communication
is prohibited. If this communication was received in error, please
notify the sender by reply E-mail immediately, and delete and destroy
the original message.
More information about the OPEN-ILS-DOCUMENTATION
mailing list