#ben_thatmustbemei don't really see a good reason for it though unless we are actually using something that requires it
#ben_thatmustbemeotherwise you are just needlessly breaking support for legacy code
#aaronpkokay, rebooting the server is no longer actually fixing the problem
#aaronpkadminhelp: does anyone know the current root password on the server so I can go in and actually look at what's going on? If not, I am happy to reset it.
#[jgarber][ben_thatmustbeme] Agreed. I’ve come around on that one. Authoring in 2.4.x (2.4.4 being the most current) and running Travis, etc. against 2.4.x, 2.5.x seems like the wiser approach.
#[jgarber][ben_thatmustbeme] Would you be hip to add me as an admin on the indieweb/microformats-ruby repo?
#ben_thatmustbemealso, by the way, the code smell score, is mostly based on the fact that functions are large, which actually was intentional to make them match the parsing spec as I remember
#ben_thatmustbemei need to look at all that code again, I would hold off on a new version release if we want to look at a full refactor like that
#ben_thatmustbemealso, updated the code-coverage branch just now to 2.4.4
#[jgarber]I’ll close out #85 (the Ruby version tracking issue).
#ben_thatmustbemei tried playing with #83 the other week and if I try to force it to work as the test suggests it should, it breaks a lot of other tests
#[jgarber]I’d be very much in favor of putting together a `microformats.rocks` test suite like we have with Micropub and Webmention (and a few other things, if memory serves…)
#[jgarber][ben_thatmustbeme] With the Ruby version changes, we’re introducing a breaking change which means the next version of the gem would be 5.0.0.
#[jgarber]Should we create a milestone for 5.0.0 and add issues to the milestone?