There have been a lot of minor changes since I last sent out such an email, I'll leave those to the release notes and instead and detail the more interesting ones.

Scoring of models is now organized around ScoringFunction objects. The look kind of like how the scoring part of a the model used to look (with evaluate calls), but are independent objects. You can create different types and instances of them (most commonly, a IMP::core::RestraintsScoringFunction from a list of restraints). They can then be used to specify how a particular optimizer or sampler scores it models (making it easier to use different scoring functions for different things). And different scoring methods can be used (eg an IMP::core::IncrementalScoringFunction when only moving a small number of particles at a time). This change resulted in a vast simplification on the code used to evaluate restraints and resulted in the fixing of many bugs. Moving forwards, it makes it easier to support multithreaded scoring (which can be done by implementing a new ScoringFunction subclass). The changes are more or less backwards compatible as basic scoring through Model::evaluate and Restraint::evaluate is still supported, so little code should need to be changed.

There is a new base class IMP::ModelObject for all objects which introduce dependencies in the model. IMP::Particle, IMP::ScoreState, IMP::Restraint, IMP::ScoringFunction and IMP::core::Mover all inherit from it. Such objects, when they are registered with the Model (either via a set_model() call or passing the Model to the constructor, or, for backwards compatibility, adding a restraint to the Model or ScoringFunction or adding a ScoreState to the Model) are considered part of the Model (until they are unregistered or destroyed). They can take action when the set of dependencies changes, so that relationships can be correctly updated when, eg, rigid bodies are destroyed or added (most classes don't do this yet). This also opens the way for IMP::core::Movers to have more intelligence, so they can, for example, weight the move probabilities based on how much a given particle contributes to a score (and properly maintain this weighting as things change).

Also, decomposing restraints into their simplest parts (eg a non-bonded list into n^2 pairwise terms), works in the obvious manner and so contexts that want to use such simple restraints (such as incremental scoring) can do so directly.

Scoring in Domino has been simplified around a single IMP::domino::RestraintCache object that provides a centralized cache for all restraints used. This provides a single point to control memory usage (by bounding the total number of cache entries), serialize and unserialize. In addition, coupled with the previous change, it removes the need for the IMP::domino::OptimizeRestraints objects as the restraint cache does that operation internally.

Many unnecessary #include statements in IMP headers have been removed. As a result, it may be necessary to add #includes to code not in the IMP repository to get it to compile. As a general rule, you should #include the header defining any symbol you use in a given .h or .cpp file (and not depend on it being indirectly included through another header).

Restraints now store (and can produce) the score returned in their last evaluate call.

I made efforts to provide backwards compatibility throughout the changes. But I did remove various methods that I though were unlikely to be used by anyone and so not worth the trouble to provide in the new internal architecture. If there is some method that I removed that you really need, email me and we can figure out a work around or can provide a backwards compatibility interface.