Re: DBI 1.615 and onwards

2010/9/21 Tim Bunce <[email protected]>:
> 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
>> <[email protected]> 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