NAME
Class::DBI::Frozen::301 - Class::DBI, frozen at 3.0.1SYNOPSIS
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.