[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#417553: release-notes: R N for Zope



Package: release-notes
Severity: wishlist

hi

I prepared a short paragraph for R N  regarding zope

see attachment (that is a -u diff w.r.t. latest CVS)

a.
Index: release-notes.en.sgml
===================================================================
RCS file: /cvs/debian-doc/ddp/manuals.sgml/release-notes/en/release-notes.en.sgml,v
retrieving revision 1.231
diff -u -r1.231 release-notes.en.sgml
--- release-notes.en.sgml	3 Apr 2007 07:14:24 -0000	1.231
+++ release-notes.en.sgml	3 Apr 2007 09:03:43 -0000
@@ -844,7 +844,7 @@
 
 	</sect1>
 	
-        <sect1><heading>Checking packages status</heading>
+        <sect1 id="package_status_and_holds"><heading>Checking packages status</heading>
 
           <p>Regardless of the method used for upgrading, it is recommended
           that you check the status of all packages first, and verify that
@@ -2473,6 +2473,43 @@
 
       </sect>
 
+      <sect id="zope"> <heading>Upgrading Zope and Plone</heading>
+	<p><prgn/Zope/ and all zope related products were updated;  &oldreleasename;
+        shipped <prgn/Zope/ 2.7 , that depends on <prgn/Python/ 2.3 ; and it
+	shipped <prgn/CMF/ 1.4 and <prgn/Plone/ 2.0.5 ; while  &releasename; instead
+	ships <prgn/Zope/ 2.9, which depends on <prgn/Python/ 2.4, <prgn/CMF/ 1.6 and <prgn/Plone/
+	2.5.1.
+	Many products were also dropped from the distribution (either because
+	  they were obsoleted, or incompatible with the newer
+          <prgn/Zope/, <prgn/CMF/ and <prgn/Plone/).</p>
+	<p>The user wishing to upgrade must beware of a known fact: there is no
+	  easy and guaranteed way to upgrade a complex <prgn/Zope/ or <prgn/Plone/ server.
+	  Even though <prgn/Plone/ contains a migration tool, indeed, due to the
+	  complexity of the <prgn/Plone/ server, it has been experienced that the
+	  automatic migration may easily fail.
+          </p>
+	<p>For this reason, it is recommended that the user willing to upgrade be
+	  able to run both the old (= &oldreleasename;) and the new (=  &releasename;) version of
+	  Debian for as long as needed for the correct migration of his <prgn/Zope/ / <prgn/Plone/
+	  services. The easiest and safest way to achieve this is to make a copy of the O.S. onto
+          another hard disk or hard disk partition, and then upgrade one of the
+          two copies , and use chroots to run the &oldreleasename; version in parallel to the
+          &releasename; version.</p>
+	<p>In case this is not possible, there is a limited possibility of running
+	  different versions of those products in the same Debian installation:
+	  it is indeed possible to concurrently keep <prgn/Zope/ 2.7 and 2.9 , and <prgn/Python/
+	  2.3 and 2.4 installed in Debian , since different versions are in
+	  packages by different names, namely <package/zope2.7/, <package/zope2.9/,
+          <package/python2.3/,
+	  <package/python2.4/. But it is very important to notice that &releasename; does not
+	  contain the &oldreleasename; versions: so, during upgrade, good care must be taken
+	  that the old version not be removed; to this end, package holding
+          (as explained in <ref id="package_status_and_holds">) may be helpful.
+ Also, the above does not apply
+	  to <prgn/Plone/, since the <package/zope-cmfplone/ package is not similarly  versioned, alas.
+	</p>
+      </sect>
+
       <sect id="php-globals"> <heading>Deprecated insecure php configurations</heading>
         <p>For many years, turning on the <tt/register_globals/ settings in PHP
         has been known to be insecure and dangerous, and this option has defaulted to

Attachment: signature.asc
Description: Digital signature


Reply to: