-Thu May 30 20:31:08 BST 2002 Nicholas Clark <nick@ccl4.org>
+Sat Sep 6 01:08:20 IST 2003 Abhijit Menon-Sen <ams@wiw.org>
+
+ Version 2.08
+
+ This release works around a 5.8.0 bug which caused hashes to not
+ be marked as having key flags even though an HEK had HEK_WASUTF8
+ set. (Note that the only reasonable solution is to silently drop
+ the flag from the affected key.)
+
+ Users of RT 3 who were seeing assertion failures should upgrade.
+ (Perl 5.8.1 will have the bug fixed.)
+
+Mon May 5 10:24:16 IST 2003 Abhijit Menon-Sen <ams@wiw.org>
+
+ Version 2.07
+
+ Minor bugfixes (self-tied objects are now correctly stored, as
+ are the results of additions larger than INT_MAX).
+
+Mon Oct 7 21:56:38 BST 2002 Nicholas Clark <nick@ccl4.org>
+
+ Version 2.06
-. 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.
+ 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>
+
+ 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