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
