Problems found locating distfiles:
Package cabocha: missing distfile cabocha-0.68.tar.bz2
Package convertlit: missing distfile clit18src.zip
Package php-enchant: missing distfile php-enchant/enchant-1.1.0.tgz
Otherwise, existing SHA1 digests verified and found to be the same on
the machine holding the existing distfiles (morden). All existing
SHA1 digests retained for now as an audit trail.
0.900 Tue 22 Sep 2015
- Support for arbitrary XML encodings
[INCOMPATIBLE CHANGE]
- Removal of ->no_generator method.
To suppress the default generator tag, specify an undef
generator.
0.863 Thu 10 Sep 2015
[INCOMPATIBLE CHANGE] - Datetime object support now via
->epoch method instead of ->strftime.
Despite the fact that this is an incompatible change, it
should actually be a nonevent for almost all users, because
every datetime module I could find that supports ->strftime
also supports ->epoch (and vice versa).
However, the ->strftime methods of many modules are (subtly
or badly) broken in the face of timezones even as their
->epoch methods work right (or else are broken subtly
enough to escape notice).
But if you have written your own datetime class, and it
has a ->strftime method but not an ->epoch method, and
you pass instance of that class to instance of this module,
then the feeds you generate that way will now be broken.
On balance, I believe that this change will unbreak vastly
more code than it breaks. Therefore I decided to switch.
0.861 Tue 06 Jan 2015
- Auto-formatting for recognised data types in date constructs
- Fixed CDATA flattener (was missing /s flag)
- Non-fatal warnings; mea maxima culpa
- Test suite cleanup
- Now uses Dist::Zilla
Do it for all packages that
* mention perl, or
* have a directory name starting with p5-*, or
* depend on a package starting with p5-
like last time, for 5.18, where this didn't lead to complaints.
Let me know if you have any this time.
a) refer 'perl' in their Makefile, or
b) have a directory name of p5-*, or
c) have any dependency on any p5-* package
Like last time, where this caused no complaints.
to trigger/signal a rebuild for the transition 5.10.1 -> 5.12.1.
The list of packages is computed by finding all packages which end
up having either of PERL5_USE_PACKLIST, BUILDLINK_API_DEPENDS.perl,
or PERL5_PACKLIST defined in their make setup (tested via
"make show-vars VARNAMES=..."), minus the packages updated after
the perl package update.
sno@ was right after all, obache@ kindly asked and he@ led the
way. Thanks!
pkgsrc changes:
- Adjusting license (perl5 license)
- Removing dependency to CORE module
Upstream changes:
0.86 (2009-06-23)
* Person constructs are properly escaped and encoded
0.85 (2009-06-23)
* Used a less finicky implementation strategy for the CDATA flattener
so hopefully it will not be buggy any more
0.83 (2009-05-25)
* Thanks to JMASTROS for spotting another bug in the XML escaping
function and contributing a test case
While we're here, declare LICENSE.
to trigger/signal a rebuild for the transition 5.8.8 -> 5.10.0.
The list of packages is computed by finding all packages which end
up having either of PERL5_USE_PACKLIST, BUILDLINK_API_DEPENDS.perl,
or PERL5_PACKLIST defined in their make setup (tested via
"make show-vars VARNAMES=...").
0.82 (2008-06-21)
* I can't believe no one noticed in such a long time that the XML
escaping function was broken. I need unit tests
* Also, the date in the changelog entry for 0.81 was wrong.
0.81 (2008-06-21)
* Put private functions in XML::Atom::SimpleFeed::YeWhoEnters and
placed methods in XML::Atom::SimpleFeed explicitly. This gets rid of
approximately 734 prefix underscores.
* It turns out Carp::Clan wasn't even necessary, Carp works
that way by default. *blush*
* More big POD cleanups (converted lots of list items to
subheadings so they're linkable and listed in the TOC).
* Throw out the pointless POD and POD coverage tests.
* Automatically escape the content of the icon, id, logo,
published, and updated elements. Oops. (CPAN RT #36961)
PR pkg/34399.
Revision history for XML-Atom-SimpleFeed:
0.8 2006 Jun 3
- Multiple consecutive internal refactors; code structure is now
actually satisfactory
- Handles multiple authors and contributors
- Support for icon and logo elements
- Big POD cleanup
- Use Carp::Clean to get rid of silly $Carp::CarpLevel juggling
- ***BACKWARDS INCOMPATIBLE API CHANGE***:
Elements such as C<link> which may appear multiple times are no
longer specified in an anonymous array, but simply given
repeatedly.
- ***BACKWARDS INCOMPATIBLE API CHANGE***:
Atom 0.3 element and attribute names are no longer supported. (No
point keeping a lot of deprecation code around in the face of a
change like the above.)
- ***BACKWARDS INCOMPATIBLE API CHANGE***:
Suppress the default C<generator> element requires calling the
C<no_generator> method instead of passing a C<generator> key to
C<new> with an undefined value.
- ***BACKWARDS INCOMPATIBLE API CHANGE***:
Well, since I'm at it, the C<save_file> method is no longer
supported. C<print> now takes a handle, though.
- Cleaned up errors and warning messages and got rid of DIAGNOSTICS
section in POD
0.8_004 2006 May 10
- Brownbag upload: forgot to update ./Changes in 0.8_003
0.8_003 2006 May 10
- Minor incremental progress; various bugfixes, some refactor.
0.8_002 2006 Apr 9
- Use builtin XML writer instead of SAX for output. This
eliminates huge amounts of redundancy.
- Big improvements in the distribution of responsibilities for
deprecation and validation checks.
- Array-based implementation rather than inside-out objects.
- Internal structure is now more logical and consistent.
0.8_001 2005 Sep 28
- Emit Atom 1.0. Documentation updated to reflect Atom 1.0.
Usage according to Atom 0.3 will transparently generate 1.0
elements but emit deprectation warnings.
- Remove _generate_entry_id and use HTTP URLs as IDs by default.
Using tag: URIs is useful for generating the ID once, up
front, so that it won't change even if the permalink does --
if the ID is generated from the permalink, we might as well
use the permalink directly.
- Use XML::SAX::Writer instead of XML::Simple for output.
This module exists to generate basic Atom syndication feeds. While it does
not provide a full, object-oriented interface into all the nooks and crannies
of Atom feeds, an Atom parser, or an Atom client API, it should be useful for
people who want to generate valid Atom feeds of their content quickly and
easily.
