1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
|
libdate-calc-perl (6.3-1) unstable; urgency=low
Since version 6.2, Date::Calc only contains a pure Perl
implementation. The XS-accelerated implementation was separated into
its own package, libdate-calc-xs-perl, and will automatically be used
when installed.
-- Florian Schlichting <fschlich@zedat.fu-berlin.de> Mon, 12 Sep 2011 21:44:37 +0200
libdate-calc-perl (6.0-1) unstable; urgency=low
In version 6.0 of Date::Calc the interface to DateCalc.c has changed. Thus
check for details `/usr/share/doc/lidate-calc-perl/README.txt.gz'.
Backward compatibility:
-----------------------
Module "Date::Calc" should be 100% backward compatible, meaning
that no changes to existing code using reasonably recent versions
of "Date::Calc" should be necessary (consult the changes history
in file "CHANGES.txt" for possible incompatible changes between
versions).
Note that when you pass an invalid language number to any of the
affected functions, you will get the previous behaviour, in which
a global variable (set by the function "Language()") determines
the language to be used.
Note again that this new language parameter in the affected functions
is optional; omitting it gives you the previous behaviour with the
global variable as well (this is where the compatibility with existing
code stems from).
When using the C library "DateCalc.c", where omitting a parameter
is not an option, passing a zero for the language is therefore the
recommended way to guarantee backward compatibility and to keep
changes to existing code to a minimum.
Modules "Date::Calc::Object" and "Date::Calendar::Year" should be
backward compatible as well (modules "Date::Calendar" and
"Date::Calendar::Profiles" have not been changed).
However, because the global variable (the one set by the function
"Language()") is not set temporarily anymore by language-dependent
methods and overridden operators (and restituted at the end, very
similar to the "local" operator in Perl), you might perceive
differences if your existing code relied on these implementation
details (some test cases in the test suite of this package tested
this and had therefore to be changed).
The advantage to be gained by all this is that now, all modules
in this package should be thread-safe and safe to be used by
several concurrently executed modules, as long as you do not
set the language using the global function "Language()" or the
CLASS method "language()" (and as long as you do not use any
other global setting, for that matter), but EXCLUSIVELY by
passing the language parameter to all functions individually
and by using the OBJECT method "language()".
By exclusively using local settings, you are also making your
code invulnerable against other, concurrent modules which still
use global settings.
-- Salvatore Bonaccorso <salvatore.bonaccorso@gmail.com> Thu, 08 Oct 2009 22:28:18 +0200
|