On Wed, Feb 05, 2003 at 04:39:04PM -0600, Dave Rolsky wrote: > On Wed, 5 Feb 2003, Tim Bunce wrote: > > > Er, I may well be missing something as I've not paid attention to this thread, > > but why not ship them both in the same distribution? Then some tests in t/*.t > > will test DT and some DT::DZ and both DT and DT::TZ being tested will be the > > ones in the distribution about to be installed. > > Assuming that we continue to pre-generate TZ data based on the Olson DB > (which may or may not happen), it makes sense to separate them because the > two code bases will change at different speeds. One DT::TZ has a firm > API and has been reasonably well debugged, it's likely that we'd only have > to make a new release when a new Olson DB is released, which happens a few > times a year. > > The DT module, OTOH, may stay in flux longer than DT::TZ, and is likely to > continue to stay immature for a longer period of time, meaning initially > it'll have many more releases. Eventually, it may become fairly stable > (dead? ;) and only see a release very infrequently.
Sure. Some modules within the DBI distribution change very rarely, but I still ship them within the DBI distribution as they're closely related and it's a convienience for the user. If size is the issue, why not generate the DT::TZ::foo modules when the user runs "perl Makefile.PL"? That would make the distribution much smaller. That's that's not okay then I'd suggest creating distributions for each of DT::TZ::Africa::*, DT::TZ::Europe::*, DT::TZ::Pacific::* etc. Add a Bundle::DateTime::TimeZone module to automate the fetch/install of all of them. Then ship the core DT::TZ modules plus one set of zones (say DT::TZ::America) in the DT distribution. Or, then again, given the relative simplicity/portability of the DT::TZ code you could just keep doing what you're doing... :) Tim.
