Update changelog

ChangeLog.md

@@ -9,16 +9,18 @@ Changes listed here are checked in to GitHub ("master" branch unless specificall
 ### Ongoing
 * Port enhanced documentation from DxCore.
 
+## Released Versions
+
 ## 2.5.5
 * **Critical Bugfix** to correct issue with uploading via optiboot.
-* Document my butchering of the board manager json and how to correct issues caused by it. (sorry!)
+* Document my butchering of the board manager json and how to correct issues caused by it. (sorry! )
 * Housekeeping in UART.h and UART.cpp
 * **Critical Bugfix** to correct attachInterrupt, which would corrupt the stack when used in the default mode. (DxCore #225)
 * Allow the DxCore names for RTC clock sources to be used.
 * **Critical Bugfix** to correct return values from Wire.endTransaction() to match the API. (DxCore #226)
-* Correct serious defect in new Wire library. The point of using 32b buffers is to match basically everything else, since having less than the assumed amount will cause failures to many libraries. However, we also stuff the slave address into the buffer, so 32 byte buffers only give us 31 bytes of data. This was detected when it broke the adafruit OLED library. Fixing it by enlarging the buffer and sacrificing power-of-2-ness cost 54-78 bytes of flash. I was able to get back around 40% of that for parts with buffer sizes under 128b (ie, all of the megaTinyCore; DxCore doesn't care since they got 130b buffers, though they need 131b or I should have just done 128b, cause we need 130b of "data" to write a 128b page to external eeproms)
+* Correct serious defect in new Wire library. The point of using 32b buffers is to match basically everything else, since having less than the assumed amount will cause failures to many libraries. However, we also stuff the slave address into the buffer, so 32 byte buffers only give us 31 bytes of data. This was detected when it broke the adafruit OLED library. Fixing it by enlarging the buffer and sacrificing power-of-2-ness cost 54-78 bytes of flash. I was able to get back around 40% of that for parts with buffer sizes under 128b (ie, all of the megaTinyCore; DxCore doesn't care since they got 130b buffers, though they need 131b or I should have just done 128b, cause we need 130b of "data" to write a 128b page to external eeproms) (#593)
+* Correct typo in boards.txt impacting old wrong-sig ATtiny402's. (#592)
 
-## Released Versions
 ## 2.5.4
 * **CRITICAL BUGFIX**. Prior critical bugfix was unsuccessful because the flashsize test was comparing it to the wrong value. Additionally, the branch before a jmp, with it's offset specified numerically, needs to match the size of the rjmp or jmp instruction;  This corrects that.
 

README.md

@@ -2,8 +2,7 @@
 ### [Check it out, we have "discussions" now!](https://github.com/SpenceKonde/megaTinyCore/discussions)
 Let's use that - it's better than gitter ever was, and it's all on one site.
 
-### 2.5.0 is here! New Wire library is in! Serial improvements are in! (Including some snazzy things like loopback support)
-Try it out! Report issues! Build awesome stuff!
+### 2.5.5 is now available. This fixes a number of critical issues with the 2.5.x versions and all users are encouraged to update.
 
 ### Notice regarding update issues
 Well, I screwed up fairly badly in handling the board manager json. The short version of the story is that I discovered a bug in 2.4.3 that required no changes to the core, just a board manager change. So I changed the json file (big mistake). Anyone who installed after that change would get a java null pointer exception when trying to upgrade. But I didn't realize this until I had already done a release in 2.5.x, then realized I'd missed that fix, and modified the board manager json after release. Then I finally made the connection between having done that and the flood of support inquiries relating to being unable to upgrade.