2010/9/21 Tim Bunce <tim.bu...@pobox.com>: > Thankfully RT#61445 hasn't turned out to be a major problem. > Presumably because none of the cpantesters, so far, are using > "~/Library/Application Support/.cpan" as their build path. > And the "whitespace characters in the current directory path" warning > that Makefile.PL issues may be helping those who build manually. > > Still, I'd like to focus for now on getting a clean stable DBI release. > So I've released the current code (r14438) as DBI-1.614_90 for > cpantesters to chew on. > > I appreciate that I've not been following developments of the pure-perl > drivers as closely as I'd like, and that that may have led to some > misunderstandings. If so, I'm sorry about that. > > To simplify future development and communication I've created a new > branch for the development of the pure-perl drivers based around > DBD::File and DBI::DBD::SqlEngine: > https://svn.perl.org/modules/dbi/branches/sqlengine > > That'll let Jens Rehsack, H.Merijn Brand and anyone else working on that > part of the code base (the "SqlEngine team"?), develop and commit freely > without having to be concerned with DBI release cycles. > > When the SqlEngine team is ready to release it can merge in the latest > trunk, test and tag it. Then I'll make a dev release from the branch. > If that tests well I'll merge it into the trunk. > > Does that sound ok?
Partially for me. 1) I don't know which svn version is used to store the repository, so we might run into trouble when merging from the trunk. 2) We should try to communicate about release cycles anyway, because it doesn't makes much sense to have the sqlengine branch ready for release a week after a fresh release is out. 3) Me might tag something as stable and ready for release, but want develop more (because we have time, desires or what ever), so we need to branch (for fixing) ... But it sounds like a way we can walk to see where it leads us. And probably I'm to pessimistic at the moment :) Probably we need more branches - depending on the task, let's see. Thanks, Jens
