Releases: cooper/juno
juno13-ava
Several new IRCv3 features were added, particularly the improved IRCv3.2 capability negotiation, cap-notify, userhost-in-names, SASL reauthentication, and the MONITOR client notification system. Additional new channel features include WHOX support, KNOCKing, join throttle mode (+j), no forward-mode (+Q), and the long-planned MODESYNC mechanism, which helps maintain network-wide channel mode synchrony even when some modes are not enabled on all servers. The built-in DNS blacklist checker now supports IPv6 blacklists and has improved caching helping to decrease the effects of malicious attacks. Further work on TS6 and JELP includes improved ban propagation and more S2S security measures.
juno12-mihret
A lot was accomplished during the short-lived development of mihret. Several new channel features were introduced, including IRCv3 extended-join, permanent channels (+P), op moderation (+z), color stripping (+c), registered only (+r), and SSL only (+S), all implemented as modules. Internal support for new user modes, deafness (+D) and bot status (+B), was also added. mihret furthered the support of external IRC services packages by reworking the SASL module to support relaying authentication over both server protocols. Nickname enforcement, nickname reservations, and channel reservations are now supported as well. For the first time in its history, juno now has a decent hostname cloaking interface with a charybdis-compatible implementation. The netban module was rewritten from the ground up in an objective fashion. New APIs make it very easy to extend netban functionality from additional modules. The TS6 netban implementation was mostly completed too. A new IRCd support interface makes it easy to add special rules for certain IRC software and also features inheritance of properties for derivative software. As usual, there were astounding improvements to TS6 and even some enhancements to JELP.
juno11-janet
Upon the release of mihret (juno12), a new versioning system was adopted. Releases now occur at the start of the next major version (in this case, v12.00), rather than at an arbitrary version as before. So janet and mihret are actually the same release. See below. This new system is less confusing and makes it easier to release patches.
juno10-yiria
An acronym for our slogan (Yes. It really is an IRC daemon.), yiria's primary goal was to complete the implementation of the TS6 protocol. Doing so while retaining support for the Juno Extensible Linking Protocol (JELP) involved efficient TS6<->JELP command conversion and vigorous mode translation, among other challenges. But we pulled through, and now juno almost fully supports a variety of TS6 servers such as charybdis and elemental-ircd, as well as many pseudoserver packages like Atheme IRC Services and PyLink relay software. Adding TS6 resulted in a positive side effect: several improvements within JELP in order to stay competitive with the newly-supported protocol. Aside from server-to-server improvements, new noteworthy features in yiria include built-in DNSBL checking, private channels, and IRCv3 away-notify support. As always, there were lots of bug fixes and efficiency improvements too.
juno9-agnie
Named after the beautiful and talented Agnes, agnie introduced lots of new functionality: the ability to manage oper flags from IRC, much-improved account management, and command aliases to name a few. It opened a new door of possibility by adding partial TS6 protocol support, and it even supports Atheme now to some extent. New channel modes include invite exception (+I), free invite (+g), channel forward (+F), oper only channel (+O), and mute ban (+Z, missing since juno2); also, the TopicAdditions module added convenient commands to prepend or append the topic. Some missing commands were added: ADMIN, TIME, and USERHOST; and several commands that previously did not work remotely now do. agnie introduced a new mechanism for storing and enforcing bans (functionality missing since juno2), followed by K-Line and D-Line support in the form of independent modules. In addition to the existing RELOAD command, agnie includes new ways to manage servers remotely, including repository and configuration management directly from IRC.
juno8-kylie
Named after the adored Kyle, kylie introduced several previously-missing core components including ident support and channel modes: limit, secret, and key. APIs for IRCv3 extensions were added, leading to SASL, multi-prefix, and message tag support. An improved IRC parser allowed drastic code cleanup and improved efficiency. A new event-driven API made user commands more extensible than ever before. The migration of all non-modular packages into modules significantly improved the stability and reloadability of the IRCd.
juno7-vulpia
Romanian for a female wolf, vulpia was named after the alias of a dear friend, Ruin. It included several improvements, making the IRCd more extensible than ever before. The Evented::API::Engine replaced the former API Engine, allowing modules to react to any event that occurs within juno. vulpia completed the relocation of JELP (the linking protocol) to an optional module, opening the doors for additional linking protocols in the future. Additionally, it established fantasy command support; the Reload module, which makes it possible to upgrade the IRCd to the latest version without restarting or disconnecting users; and a new Account module, helping users to better manage nicknames and channels.
juno6-kedler
Named after a Haitian computer technician, kedler was a continuation of juno5. Its main goal was to implement the missing standard IRC functions that had never been implemented in the third juno generation. kedler reintroduced hostname resolving, a long-broken feature that had not worked properly since juno2. kedler featured new APIs and improvements to the linking protocol.
juno5
It turned out that mesh linking required more code and effort than intended and introduced countless bugs that I didn't want to bother correcting. I knew that if I started from scratch again, it would never reach the completeness of the previous generation. Therefore, juno5 was born as yet another fork with a new versioning system. It removed the mesh linking capability while preserving the other new features that were introduced in juno-mesh. juno5 also reintroduced channel access (+A), this time in the form of a module.