NAME
Class::DBI::Frozen::301 - Class::DBI, frozen at 3.0.1
SYNOPSIS
use Class::DBI::Frozen::301;
... Class::DBI-using app as normal ...
With the rapid changes in Class::DBI and the author's refusal to
participate in the community or effectively liaise with developers of
dependent apps to ensure that plugin authors are warned of changes in
order to avoid breakage, a substantial number of users have frozen their
production systems at 0.96 or 3.0.1. This is designed to make that
easier, and to allow other users of the same system to use whatever
Class::DBI version they prefer.
The rest of this POD is identical to the original from 3.0.1; the
section titled 'RELEASE PHILOSOPHY' should make the reason for this
package abundantly clear.
CURRENT AUTHOR
Tony Bowden
AUTHOR EMERITUS
Michael G Schwern
THANKS TO
Tim Bunce, Tatsuhiko Miyagawa, Perrin Hawkins, Alexander Karelas, Barry
Hoggard, Bart Lateur, Boris Mouzykantskii, Brad Bowman, Brian Parker,
Casey West, Charles Bailey, Christopher L. Everett Damian Conway, Dan
Thill, Dave Cash, David Jack Olrik, Dominic Mitchell, Drew Taylor, Drew
Wilson, Jay Strauss, Jesse Sheidlower, Jonathan Swartz, Marty Pauley,
Michael Styer, Mike Lambert, Paul Makepeace, Phil Crow, Richard
Piacentini, Simon Cozens, Simon Wilcox, Thomas Klausner, Tom Renfro, Uri
Gutman, William McKee, the Class::DBI mailing list, the POOP group, and
all the others who've helped, but that I've forgetten to mention.
RELEASE PHILOSOPHY
Class::DBI now uses a three-level versioning system. This release, for
example, is version 3.0.1
The general approach to releases will be that users who like a degree of
stability can hold off on upgrades until the major sub-version increases
(e.g. 3.1.0). Those who like living more on the cutting edge can keep up
to date with minor sub-version releases.
In general the minor-version releases will be for bug fixes and
refactorings, whereas new functionality will be held-off until major
sub-version releases.
Of course, these aren't hard and fast rules, and we'll need to see how
this all goes.
Getting changes accepted
There is an active Class::DBI community, however I am not part of it. I
am not on the mailing list, and I don't follow the wiki. I also do not
follow Perl Monks or CPAN reviews or annoCPAN or whatever the tool du
jour happens to be.
If you find a problem with Class::DBI, by all means discuss it in any of
these places, but don't expect anything to happen unless you actually
tell me about it.
The preferred method for doing this is via the CPAN RT interface, which
you can access at http://rt.cpan.org/ or by emailing
bugs-Class-DBI@rt.cpan.org
If you email me personally about Class::DBI issues, then I will probably
bounce them on to there, unless you specifically ask me not to.
Otherwise I can't keep track of what all needs fixed. (This of course
means that if you ask me not to send your mail to RT, there's a much
higher chance that nothing will every happen about your problem).
Bug Reports
If you're reporting a bug then it has a much higher chance of getting
fixed quicker if you can include a failing test case. This should be a
completely stand-alone test that could be added to the Class::DBI
distribution. That is, it should use Test::Simple or Test::More, fail
with the current code, but pass when I fix the problem. If it needs to
have a working database to show the problem, then this should preferably
use SQLite, and come with all the code to set this up. The nice people
on the mailing list will probably help you out if you need assistance
putting this together.
You don't need to include code for actually fixing the problem, but of
course it's often nice if you can. I may choose to fix it in a different
way, however, so it's often better to ask first whether I'd like a
patch, particularly before spending a lot of time hacking.
Patches
If you are sending patches, then please send either the entire code that
is being changed or the output of 'diff -Bub'. Please also note what
version the patch is against. I tend to apply all patches manually, so
I'm more interested in being able to see what you're doing than in being
able to apply the patch cleanly. Code formatting isn't an issue, as I
automagically run perltidy against the source after any changes, so
please format for clarity.
Patches have a much better chance of being applied if they are small.
People often think that it's better for me to get one patch with a bunch
of fixes. It's not. I'd much rather get 100 small patches that can be
applied one by one. A change that I can make and release in five minutes
is always better than one that needs a couple of hours to ponder and
work through.
I often reject patches that I don't like. Please don't take it
personally. I also like time to think about the wider implications of
changes. Often a *lot* of time. Feel free to remind me about things that
I may have forgotten about, but as long as they're on rt.cpan.org I will
get around to them eventually.
Feature Requests
Wish-list requests are fine, although you should probably discuss them
on the mailing list (or equivalent) with others first. There's quite
often a plugin somewhere that already does what you want.
In general I am much more open to discussion on how best to provide the
flexibility for you to make your Cool New Feature(tm) a plugin rather
than adding it to Class::DBI itself.
For the most part the core of Class::DBI already has most of the
functionality that I believe it will ever need (and some more besides,
that will probably be split off at some point). Most other things are
much better off as plugins, with a separate life on CPAN or elsewhere
(and with me nowhere near the critical path). Most of the ongoing work
on Class::DBI is about making life easier for people to write extensions
- whether they're local to your own codebase or released for wider
consumption.
SUPPORT
Support for Class::DBI is mostly via the mailing list.
To join the list, or read the archives, visit
http://lists.digitalcraftsmen.net/mailman/listinfo/classdbi
There is also a Class::DBI wiki at http://www.class-dbi.com/
The wiki contains much information that should probably be in these docs
but isn't yet. (See above if you want to help to rectify this.)
As mentioned above, I don't follow the list or the wiki, so if you want
to contact me individually, then you'll have to track me down
personally.
There are lots of 3rd party subclasses and plugins available. For a list
of the ones on CPAN see:
http://search.cpan.org/search?query=Class%3A%3ADBI&mode=module
An article on Class::DBI was published on Perl.com a while ago. It's
slightly out of date , but it's a good introduction:
http://www.perl.com/pub/a/2002/11/27/classdbi.html
The wiki has numerous references to other articles, presentations etc.
http://poop.sourceforge.net/ provides a document comparing a variety of
different approaches to database persistence, such as Class::DBI,
Alazabo, Tangram, SPOPS etc.
LICENSE
This library is free software; you can redistribute it and/or modify it
under the same terms as Perl itself.
SEE ALSO
Class::DBI is built on top of Ima::DBI, DBIx::ContextualFetch,
Class::Accessor and Class::Data::Inheritable. The innards and much of
the interface are easier to understand if you have an idea of how they
all work as well.