Support numpy 1.10 (master) by adding support for np.cbrt [closes #2936]
Correct determination of scaling in NDUncertainty.uncertainty.setter
Adds basic registries (just a set) of knowing model and fitter classes.
Fixes #2711
Merge pull request #2711 from embray/fits/issue-2711

FITS: 'BLANK' keyword causes crash when reading data
Merge pull request #2725 from embray/modeling/registry

Adds Model and Fitter class registries
Fixes #2710
Merge pull request #2710 from embray/fits/issue-2710

FITS objects created with `fromstring` have problems?
Fix a small syntactic type in tokenizer.c

This change I think is logically equivalent, but certainly "bitwise and"
was not intended here.  gcc 4.8 complains about it:

    astropy/io/ascii/src/tokenizer.c:683:20: warning: suggest parentheses around comparison in operand of ‘&’ [-Wparentheses]
         p += (tsep != '\0' & *p == tsep);
Merge pull request #2954 from mdboom/io.ascii/syntactic-typo

Fix a small syntactic typo in tokenizer.c
Update CHANGES.rst

Fix misplayed changelog entry for #2879
Update CHANGES.rst

Fixed another misplaced changelog entry
Some PEP-8 'cleanup' and a little bit of variable renaming particularly in FrameMeta.__new__ to follow more conventional naming
Add approximate comparison in wcscompare()
Slight clarification of this 'hack' I think (and avoids creating one
unnecessary list).

I was thinking of adding this recipe [1] to Astropy's utils and using it
to compute the MRO, which I think is a bit nicer.  But some performance
testing showed it not to be significantly faster in most cases, so I
stuck with the temp class creation which is not too horrible after all.

[1] http://code.activestate.com/recipes/577748-calculate-the-mro-of-a-class/
Update wcslib to 4.24
Add CHANGES entry
Merge pull request #2503 from mdboom/wcs/fuzzy-compare

WCS comparison can fail for least-significant-digit comparison
Merge pull request #2937 from mhvk/numpy-dev-1.10

Support numpy 1.10 (master) by adding support for np.cbrt [closes #2936]
A simplistic solution to providing some proper ordering to FrameAttributes.  This should provide a reasonable enough solution to #2845 in the cases we care about right now.  The only visible change to users is that the return value of get_frame_attr_names is now an OrderedDict instead of just a dict.  But that should't affect any actual results.