This is the mail archive of the
gsl-discuss@sourceware.org
mailing list for the GSL project.
Re: GSL 2.0 roadmap
- From: Tuomo Keskitalo <Tuomo dot Keskitalo at iki dot fi>
- To: Brian Gough <bjg at gnu dot org>
- Cc: GSL Discuss Mailing List <gsl-discuss at sourceware dot org>
- Date: Thu, 27 Aug 2009 14:42:12 +0300
- Subject: Re: GSL 2.0 roadmap
- References: <48E25CA9.6080306@iki.fi> <490DE4BD.7070907@iki.fi> <m3y700znqd.wl%bjg@network-theory.co.uk> <497B00F6.2080400@iki.fi> <m38woqp3je.wl%bjg@network-theory.co.uk> <498727E5.6080407@iki.fi> <49AA9DB5.6030908@iki.fi> <49FB01D1.30000@iki.fi> <m3ljp7amw3.wl%bjg@network-theory.co.uk> <4A7ADFDC.9080408@iki.fi> <m3r5v4527i.wl%bjg@network-theory.co.uk>
Hello,
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?
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).
On 08/21/2009 11:41 PM, Brian Gough wrote:
* Changes for Release 2.0
Break binary compatibility, but keep source compatibility.
Does "source compatibility" mean that user interfaces / APIs should not
be changed?
** Convert to BZR? (check GPG signing and integrity guarantees)
Do you mean http://bazaar-vcs.org/Bzr ?
Would this mean to abandon git?
--
Tuomo.Keskitalo@iki.fi
http://iki.fi/tuomo.keskitalo