[Quantlib-dev] Road to 1.0

[Luigi B. <lui...@gm...>]

Hi all,
	I guess we should start making plans if we want to get release 1.0 out
this year. Here's what I'm thinking: please follow up if you have any
comments or additions.

Thanks,
	Luigi

-----------------------------------------------

1) scope of the release:

What we have now, plus the contributions I had in the past few months.
They include credit and commodity frameworks, which are the most
important pieces we're missing. I'll add them to the repository during
the next weeks.


2) goals:

- Coverage (which is pretty much ok, see point (1) above.)

- Documentation. Not quite enough right now. At the very minimum, we
should add more examples to showcase other parts of the library (bond
calculations spring to mind, for instance.)

- Stability (which has been a sore point for the last few releases.)
The idea is that client code written against 1.0 should keep compiling
against any future 1.x.y release. This means that once 1.0 is out, the
interfaces cannot be changed (note that since we're providing a library,
the interfaces include the protected methods and data members,) files
cannot be renamed or moved, and code cannot be moved from one header
file to another. Of course, new files, classes, methods and/or data
members can still be added.  Three notes: a) one way to ensure stability
is to freeze the test-suite and example code. We can add new examples
and test cases, but the existing ones should not be changed. This will
give us a decent code base (about 50k lines) against which backward
compatibility can be checked. b) we should determine what interfaces
still need to be changed (as in "agree on a list and stick to it", more
on this in point (4) below) and make the changes before 1.0.  c) This
does not apply to stuff in the ql/experimental folder, which is fair
game until it's moved out (at which point, it freezes.)


3) schedule:
shortly before 1.0, I'd put out a 0.9.9 release---kind of a beta, if you
like. We might call it 1.0b1, too, but I suspect that more people will
try it out if there's no "beta" label attached. Release 1.0 would come
out about a month after, when we've seen that there's no obvious
problems in 0.9.9. The release branch for 1.0 might actually be made
from the 0.9.9 branch, to ensure that new stuff on the trunk doesn't
break anything. The 0.9.9 interfaces should be almost frozen---changes
from 0.9.9 to 1.0 should have a compelling reason.

Depending on how fast we're working, 0.9.9 might be the next release.
But it seems more probable that we'll have a 0.9.5 in April or May, the
0.9.9 in the summer, and the 1.0 shortly after.


4) list of breaking changes:
The ones that I would make are:

- engine refactoring for a few instruments (asset swap, variance swap,
inflation swaps...)  The idea is to put market data in the engine, as we
did for swaps and bonds.

- decrease the number of template parameters in IterativeBootstrap, from
<Curve,Traits,Interpolator> to just <Curve>. The other parameters can be
retrieved from the curve as typedefs. It increases a bit the
readability, and shouldn't break much code (I doubt that many people
wrote their own curve based on it yet.)

- clearer instantiation of a few Monte Carlo engines, by replacing
withTolerance() with both withRelativeTolerance() and
withAbsoluteTolerance(). The ambiguity has bitten us already in the
past.

- finally, if I can make a request (most likely, I won't be doing this
one myself): would it be possible to have a look at the SwaptionVolCube1
and SwaptionVolCube2 classes and see whether they can be merged? At
least, they should be given names that describe their differences.



-- 

No, I'm not interested in developing a powerful brain. All I'm after 
is just a mediocre brain, something like the president of American 
Telephone and Telegraph Company. 
-- Alan Turing on the possibilities of a thinking machine, 1943.