As far as I know, the plan for hard forks is to always release the code for a hard fork approximately six months into the main repository as a point release before the hard fork code activates. However, there was some issue recently (mid-December 2016), that requires all users to update their clients again before the next hardfork in early January 2017. What was the issue that resulted in everyone being required to update in a matter of a few weeks? How was it resolved? Links to Github commits would be appreciated, but also a plain English (as much as possible) explanation as well.
First, some background. In MRL-0005 - Ring Confidential Transactions there's a section on range proofs, relevant quotes below.
5 Aggregate Schnorr Range Proofs
In , the confidential transactions without ring signatures uses a type of ring signature based on  called a Borromean ring signature, which helps to prove a committed value lies within a certain range. In this article, I will outline an alternative method, inspired by , which has the same space savings, but perhaps simpler security proofs.
For space savings, one can either use a Borromean ring signature (as in ) to combine all of these simple ring signatures, or a type of aggregate ring signature defined as follows:
5.0.1 Aggregate Schnorr Non-linkable Ring Signature (ASNL) Generation
Now, why do we need these? From the same paper (emphasis mine):
... as -1 is a very large number modulo the curve group order, free money has been created. It is therefore necessary to prove that the C_out,i are commitments to values which are positive and lie in a restricted range [0,2^n] for some n.
These signatures are used to prove that one is not using just anything to hide the amounts, ie to prove what I've highlighted above. It's important because allowing just anything would make it possible to cheat the
sum(ins) == sum(outs) part of transaction verification. Thus, it's important that the proof be air-tight.
Now, an issue had been discovered with proof for ASNL signatures used in ringCT. If I understand well, it would open a theoretical possibility of someone forging the range proof somehow. Because of this, it had to be changed from ASNL to Borromean signatures.
If there was no update, everyone running the already deployed code of 0.10.0 would move on and start making rCT-ASNL transactions, but the theoretical problem would still be there and present an unnecessary risk.
Thankfully, at the time of this writing, there's still approx. 27 days until the HF (as reported by