From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1105 invoked by alias); 28 Aug 2009 13:58:10 -0000 Received: (qmail 1095 invoked by uid 22791); 28 Aug 2009 13:58:09 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,DATE_IN_PAST_03_06,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.network-theory.co.uk (HELO mail.network-theory.co.uk) (66.199.228.187) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 28 Aug 2009 13:58:03 +0000 Date: Fri, 28 Aug 2009 13:58:00 -0000 Message-ID: <871vmwuvb0.wl%bjg@network-theory.co.uk> From: Brian Gough To: Tuomo Keskitalo Cc: GSL Discuss Mailing List Subject: Re: GSL 2.0 roadmap In-Reply-To: <4A967114.8080600@iki.fi> References: <48E25CA9.6080306@iki.fi> <490DE4BD.7070907@iki.fi> <497B00F6.2080400@iki.fi> <498727E5.6080407@iki.fi> <49AA9DB5.6030908@iki.fi> <49FB01D1.30000@iki.fi> <4A7ADFDC.9080408@iki.fi> <4A967114.8080600@iki.fi> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Message-Mac: 76d49bdd8221975bfeb889c669cb452c Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org X-SW-Source: 2009-q3/txt/msg00025.txt.bz2 At Thu, 27 Aug 2009 14:42:12 +0300, Tuomo Keskitalo wrote: > thanks for the list. I was wondering that since there will be a new > major version, this might be a good chance to modify some of the > APIs / frameworks. Is this OK? For example, when I was implementing > msadams and msbdf for ode-initval, I had to make some modifications > to the algorithms in order to fit them into GSL ode-initval > framework. It is clear that the stepper, control and evolve objects > would sometimes benefit from mutual communication. Should > ode-initval framework be changed so that this kind of communication > is possible in future? Yes, we could do that wherever there is a clear benefit. > How long would it be before 2.0 is out, approximately? More or less than > a year? It might be good idea to keep the 2.0 branch "unstable" for some > time, before APIs are frozen (if changes to frameworks are OK). Hopefully less than a year. I still try to make a release every six months (more or less). > Does "source compatibility" mean that user interfaces / APIs should not > be changed? I think I meant to write "keep source compatibility where possible" (i.e. for rearranging structs) . For some changes, we will need to break that. > > ** Convert to BZR? (check GPG signing and integrity guarantees) > > Do you mean http://bazaar-vcs.org/Bzr ? > Would this mean to abandon git? Bzr is now the standard GNU version control system, so it would mean abandoning git, yes. The timing of switching to git was unfortunate, as the announcement about Bzr was not long after, but there wasn't any way to know that before. However, switching again isn't a high priority. -- Brian Gough