Try to make PPPort.pm 5.005-friendlier (see [perl #21339]).
[p5sagit/p5-mst-13.2.git] / ext / Storable / ChangeLog
index 1480983..74bad2e 100644 (file)
@@ -1,36 +1,81 @@
+Mon Oct  7 21:56:38 BST 2002   Nicholas Clark  <nick@ccl4.org>
+
+    Version 2.06
+
+       Remove qr// from t/downgrade.t so that it will run on 5.004
+       Mention $File::Spec::VERSION a second time in t/forgive.t so that it
+       runs without warnings in 5.004 (this may be a 5.00405 bug I'm working
+       round)
+       Fix t/integer.t initialisation to actually generate 64 bits of 9c
+       Fix comparison tests to use eval to get around 64 bit IV conversion
+       issues on 5.6.x, following my t/integer.t ^ precedence bug found by
+       Rafael Garcia-Suarez
+       Alter t/malice.t to work with Test/More.pm in t/, and skip individual
+       subtests that use $Config{ptrsize}, so that the rest of the test can
+       now be run with 5.004
+       Change t/malice.t and the error message in check_magic in Storable.xs
+       from "Pointer integer size" to "Pointer size"
+       Remove prerequisite of Test::More from Makefile.PL
+       Ship Test::Builder, Test::Simple and Test::More in t
+
+Thu Oct  3 08:57:22 IST 2002   Abhijit Menon-Sen <ams@wiw.org>
+
+    Version 2.05
+
+        Adds support for CODE references from Slaven Rezic
+        <slaven.rezic@berlin.de>.
+
+Fri Jun  7 23:55:41 BST 2002   Nicholas Clark
+
+    Version 2.04
+
+       Bug fix from Radu Greab <radu@netsoft.ro> (plus regression test)
+       to fix a recently introduced bug detected by Dave Rolsky.
+       Bug was that for a non threaded build, the class information was
+       being lost at freeze time on the first object with a STORABLE_freeze
+       hook. Consequentially the object was not blessed at all when thawed.
+       (The presence (or lack) of STORABLE_thaw was irrelevant; this was
+       a store-time data lost bug, caused by failure to initialize internal
+       context)
+       The bug was introduced as development perl change 16442 (on
+       2002/05/07), so has been present since 2.00.
+       Patches to introduce more regression tests to reduce the chance of
+       a reoccurance of this sort of goof are always welcome.
+       
 Thu May 30 20:31:08 BST 2002   Nicholas Clark <nick@ccl4.org>
 
-. Description:
-
-       Version 2.03    Header changes on 5.6.x on Unix where IV is long long
-
-       5.6.x introduced the ability to have IVs as long long.  However,
-       Configure still defined BYTEORDER based on the size of a long.
-       Storable uses the BYTEORDER value as part of the header, but doesn't
-       explicity store sizeof(IV) anywhere in the header.  Hence on 5.6.x
-       built with IV as long long on a platform that uses Configure (ie most
-       things except VMS and Windows) headers are identical for the different
-       IV sizes, despite the files containing some fields based on sizeof(IV)
-
-       5.8.0 is consistent; all platforms have BYTEORDER in config.h based on
-       sizeof(IV) rather than sizeof(long).  This means that the value of
-       BYTEORDER will change from (say) 4321 to 87654321 between 5.6.1 and
-       5.8.0 built with the same options to Configure on the same machine.
-       This means that the Storable header will differ, and the two versions
-       will wrongly thing that they are incompatible.
-
-       For the benefit of long term consistency, Storable now implements the
-       5.8.0 BYTEORDER policy on 5.6.x.  This means that 2.03 onwards default
-       to be incompatible with 2.02 and earlier (ie the large 1.0.x installed
-       base) on the same 5.6.x perl.
-
-       To allow interworking, a new variable $Storable::interwork_56_64bit
-       is introduced.  It defaults to false.  Set it to true to read and
-       write old format files.  Don't use it unless you have existing
-       stored data written with 5.6.x that you couldn't otherwise read,
-       or you need to interwork with a machine running older Storable on
-       a 5.6.x with long long IVs.  ie you probably don't need to use it.
-       
+    Version 2.03        Header changes on 5.6.x on Unix where IV is long long
+
+        5.6.x introduced the ability to have IVs as long long.  However,
+        Configure still defined BYTEORDER based on the size of a long.
+        Storable uses the BYTEORDER value as part of the header, but
+        doesn't explicity store sizeof(IV) anywhere in the header.
+        Hence on 5.6.x built with IV as long long on a platform that
+        uses Configure (ie most things except VMS and Windows) headers
+        are identical for the different IV sizes, despite the files
+        containing some fields based on sizeof(IV)
+
+        5.8.0 is consistent; all platforms have BYTEORDER in config.h
+        based on sizeof(IV) rather than sizeof(long).  This means that
+        the value of BYTEORDER will change from (say) 4321 to 87654321
+        between 5.6.1 and 5.8.0 built with the same options to Configure
+        on the same machine.  This means that the Storable header will
+        differ, and the two versions will wrongly thing that they are
+        incompatible.
+
+        For the benefit of long term consistency, Storable now
+        implements the 5.8.0 BYTEORDER policy on 5.6.x.  This means that
+        2.03 onwards default to be incompatible with 2.02 and earlier
+        (ie the large 1.0.x installed base) on the same 5.6.x perl.
+
+        To allow interworking, a new variable
+        $Storable::interwork_56_64bit is introduced. It defaults to
+        false. Set it to true to read and write old format files. Don't
+        use it unless you have existing stored data written with 5.6.x
+        that you couldn't otherwise read, or you need to interwork with
+        a machine running older Storable on a 5.6.x with long long IVs
+        (i.e., you probably don't need to use it).
+
 Sat May 25 22:38:39 BST 2002   Nicholas Clark <nick@ccl4.org>
 
     Version 2.02