Re: DBI 1.615 and onwards
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
Re: DBI 1.615 and onwards
On Tue, 21 Sep 2010 11:25:41 +0100, Tim Bunce tim.bu...@pobox.com wrote: 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. That will mean that someone other than me will have to keep merging commits to the main branch over to the sqlengine branch. I'm very short on hacking time already and am not into a position to delve into how svn branches work. 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? whatever makes the final release more stable and trustworthy. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBI 1.615 and onwards
On Tue, 21 Sep 2010 13:21:53 +0200, Jens Rehsack rehs...@googlemail.com wrote: 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. Tim, would it be OK to release dev versions of `other' branches to CPAN? So the CPANTESTERS can pick up what goes wrong -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBI 1.615 and onwards
2010/9/21 H.Merijn Brand h.m.br...@xs4all.nl: On Tue, 21 Sep 2010 11:25:41 +0100, Tim Bunce tim.bu...@pobox.com wrote: 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. That will mean that someone other than me will have to keep merging commits to the main branch over to the sqlengine branch. I'm very short on hacking time already and am not into a position to delve into how svn branches work. I can handle that, I know svn branches since svn 1.3 (first release I really worked with). 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? whatever makes the final release more stable and trustworthy. /me nods /Jens
Re: DBI 1.615 and onwards
On Tue, Sep 21, 2010 at 01:56:49PM +0200, H.Merijn Brand wrote: On Tue, 21 Sep 2010 13:21:53 +0200, Jens Rehsack rehs...@googlemail.com wrote: 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. I believe the server is 1.6.9 (Server:Apache/2.2.14 (Unix) DAV/2 SVN/1.6.9 mod_python/3.3.2-dev-20080819 Python/2.4.1 mod_ssl/2.2.14 OpenSSL/0.9.8e-fips-rhel5 mod_fastcgi/2.4.6 mod_perl/2.0.4 Perl/v5.8.8) 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. Naturally. 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) ... Sure. I'd merge the tagged version, rather than the current branch head, into trunk. If a hot fix is needed it could be cherry-picked (so to speak) later. 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. Tim, would it be OK to release dev versions of `other' branches to CPAN? So the CPANTESTERS can pick up what goes wrong Yes. That's what I meant by: 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. Tim.
Re: DBI 1.615 and onwards
2010/9/21 Tim Bunce tim.bu...@pobox.com: On Tue, Sep 21, 2010 at 01:56:49PM +0200, H.Merijn Brand wrote: On Tue, 21 Sep 2010 13:21:53 +0200, Jens Rehsack rehs...@googlemail.com wrote: 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. I believe the server is 1.6.9 (Server:Apache/2.2.14 (Unix) DAV/2 SVN/1.6.9 mod_python/3.3.2-dev-20080819 Python/2.4.1 mod_ssl/2.2.14 OpenSSL/0.9.8e-fips-rhel5 mod_fastcgi/2.4.6 mod_perl/2.0.4 Perl/v5.8.8) But is the repository converted (svnadmin upgrade or svnadmin dump + svnadmin load)? Merge tracking is available for 1.6 repositories only. 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. Naturally. 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) ... Sure. I'd merge the tagged version, rather than the current branch head, into trunk. If a hot fix is needed it could be cherry-picked (so to speak) later. Let's see how good the merge tracking is in real life :) I can take care for merging from trunk into the branch. 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. Tim, would it be OK to release dev versions of `other' branches to CPAN? So the CPANTESTERS can pick up what goes wrong Yes. That's what I meant by: 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. Tim. Jens
