IMHO, viper, your personal definition of "plenty of advance notice" is way too short. Case in point is adding CIDR support. That patch wasn't in svn for more than a few days. We all know that real life interferes with IRC. Some people don't get on everyday, every hour .. many don't do an svn check out everyday. Even as a QA I didn't have the time to checkout CIDR before the next dev release and I _do_ watch the bug tracker, I just simply hadn't the time. Thankfully none of my modules should be affected by changes after .21. However, this thread is proof that my more privately expressed concerns are right on target.
I'd also like to get something perfectly clear. Just because a specific release was out for longer than expected, it's not automaticlly obsolete. So what if .21 was out a year? Appearently it was stable enough as it was, but nope .. since it's old it must be replaced. .22 and forward has caused 10 times the headaches that .21 ever did. That should be a clue.
Here's an idea. Instead of just blindly going by age of the last stable release, why not take a poll and see what Anope's users want. Ask them if they want life sql in 1.8. Ask them id they want a fully functional BotServ with included, CORE bs fantasy commands, ask them if they want os ignores to be saved to db instead of only cached, ask if they'd like the option to have vHosts in NickServ instead of HostServ, ask them if they would like a HelpServ that is actually helpful that runs on trouble tickets instead of the pathetic waste of resources that it currently is (which by the way the current helpserv style was invented in 1994, it's now 2008 .. that's 14 years), ask them if they'd like to be able to mlock modes like +f and +j in 1.8. Ask them if they'd like to have all Serv bots optional, ask if they would like the choice of choosing AuthServ vs NickServ, Ask them if they are willing to wait while all this is added for 1.8 or if they'd rather have 1.8 as-is and wait for Anope 2.0 which could easily be another 2 years before getting such features that already exist in other services packages today.
The fact that there are few/no active module coders proves that anope can't sit around and wait for mod authors to pick up the slack. Additionally, your top 10 modules should be considered a list of desired features. Applications are designed with the USER in mind, not the desires of the development team in hopes the users agree.
I'm seriously not trying to be difficult, I'm speaking as an experienced Net Admin that likes and usually uses Anope speaking his mind about what he'd like to see in Anope. I also think that the Anope Team should ask themselves why the anope-ng team exists. Is it an attept as a fork? is it because they feel Anope is slacking? .. why? Appearently there is enough interest in Anope to evolve. I've said before that the anope-ng, Anope and denora team sohuld join forces into 1 team and fix Anope so it's more state of the art and not something left over from 1996. There is alot of talent in those 3 groups and I see no reason why they can't team up and build something useful that doesn't rely on talanted users to expand upon via modules.
Anope 1.7's cmd set is not vastly different than Anope 1.6 nor the version of Epona that it was forked from nor current Epona for that fact. Which isn't much different than IRC Services 1.4 which is similar to DALnet Services cmd set from the late 90's. All this time has been spent on back-end and modularity, which I agree is important .. but don't you think that the users would like to see and feel a more modern cmd set from todays services packages? I know I would.
Respectfully,