]>
Commit | Line | Data |
---|---|---|
3bd189cb JR |
1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> |
2 | <HTML> | |
3 | <HEAD> | |
4 | <TITLE> [IRCServices] Services 5.1pre0 released | |
5 | </TITLE> | |
6 | <LINK REL="Index" HREF="index.html" > | |
7 | <LINK REL="made" HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20Services%205.1pre0%20released&In-Reply-To="> | |
8 | <META NAME="robots" CONTENT="index,nofollow"> | |
9 | <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> | |
10 | <LINK REL="Previous" HREF="005265.html"> | |
11 | <LINK REL="Next" HREF="005274.html"> | |
12 | </HEAD> | |
13 | <BODY BGCOLOR="#ffffff"> | |
14 | <H1>[IRCServices] Services 5.1pre0 released</H1> | |
15 | <B>Andrew Church</B> | |
16 | <A HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20Services%205.1pre0%20released&In-Reply-To=" | |
17 | TITLE="[IRCServices] Services 5.1pre0 released">achurch at achurch.org | |
18 | </A><BR> | |
19 | <I>Sun May 6 17:18:19 PDT 2007</I> | |
20 | <P><UL> | |
21 | <LI>Previous message: <A HREF="005265.html">[IRCServices] Feature request | |
22 | </A></li> | |
23 | <LI>Next message: <A HREF="005274.html">[IRCServices] Services 5.1pre0 released | |
24 | </A></li> | |
25 | <LI> <B>Messages sorted by:</B> | |
26 | <a href="date.html#5262">[ date ]</a> | |
27 | <a href="thread.html#5262">[ thread ]</a> | |
28 | <a href="subject.html#5262">[ subject ]</a> | |
29 | <a href="author.html#5262">[ author ]</a> | |
30 | </LI> | |
31 | </UL> | |
32 | <HR> | |
33 | <!--beginarticle--> | |
34 | <PRE> After close to three years of work, Services 5.1 has finally reached | |
35 | beta status, and Services 5.1pre0 has now been released. It can be | |
36 | downloaded from the usual sites: | |
37 | ||
38 | <A HREF="http://www.ircservices.za.net/download/testing/">http://www.ircservices.za.net/download/testing/</A> (Japan) | |
39 | <A HREF="ftp://ftp.esper.net/ircservices/testing/">ftp://ftp.esper.net/ircservices/testing/</A> (Western USA) | |
40 | ||
41 | 75e0b3c432239bd392fc3834cadc28b0 ircservices-5.1pre0.tar.gz | |
42 | 8e32697bee2282ce98dd14df6bbe2150 ircservices-5.1pre0-1.i386.rpm | |
43 | 2ba786a9bf6e175887a926d219286844 ircservices_5.1pre0-1_i386.deb | |
44 | ||
45 | The mirrors should have it shortly. | |
46 | ||
47 | While not a stable release, I am announcing this version here (and | |
48 | will announce future beta versions on this list as well) for two reasons. | |
49 | One is that, while I am hesitant to label it "stable" before it has seen | |
50 | widespread testing, the code itself is pretty solid, and should be usable | |
51 | in production environments. I will, of course, respond to bugs as quickly | |
52 | as I can, but I'd like to recommend that those of you currently using 5.0 | |
53 | upgrade to 5.1 at your convenience, even before the stable release. I will | |
54 | also continue to support version 5.0 until 5.1 reaches stable status. | |
55 | ||
56 | The second, and more important, reason for posting the announcement | |
57 | to this list is that I intend version 5.1 to be the last version of IRC | |
58 | Services, at least under my care. While I don't consider Services | |
59 | "complete"--software development is a neverending task, and in any case | |
60 | users' needs change over time--I do believe that it's time for me to move | |
61 | on to other things. In fact, I already devote a fair amount of my time | |
62 | outside of work to other software development projects (such as the | |
63 | audio/video tool "transcode", for those who are familiar with it), and I | |
64 | have other hobbies which I haven't been able to pursue as much as I'd | |
65 | like. I've also found that I personally use IRC very infrequently these | |
66 | days, and that has inevitably lessened my interest in continuing Services | |
67 | development as well. | |
68 | ||
69 | I certainly don't believe that IRC itself is a dead or obsolete | |
70 | protocol, and I've spent the better part of the past year writing a | |
71 | detailed technical manual for Services, found in the "docs/tech" directory | |
72 | of the distribution, so that other developers can pick up as easily as | |
73 | possible where I'm leaving off. Even after the release of 5.1.0, I will | |
74 | continue to monitor the mailing lists and maintain Services 5.1 to the | |
75 | extent of fixing bugs and making other reasonably small changes. In terms | |
76 | of major improvements and additions, however, 5.1.0 will be the "final | |
77 | form" of Services for IRC Networks. | |
78 | ||
79 | For this reason, I'd like to encourage discussion of beta versions of | |
80 | 5.1 on this list, rather than on the coding list as has been done in the | |
81 | past. I'll continue to accept new feature suggestions until the release of | |
82 | 5.1.0, so if there is something you'd like to see added, feel free to bring | |
83 | it up on this list. (However, I will as always exercise my discretion in | |
84 | choosing whether a suggested feature should be added, as described in FAQ | |
85 | Z.5; I'm not going to bloat the program just because it's the last version. | |
86 | The module system is available as always for third parties to add anything | |
87 | I decide to leave out, and it has been improved for 5.1--in particular, | |
88 | modules can now save data to persistent storage without any modification of | |
89 | the core Services code.) | |
90 | ||
91 | In addition to feature suggestions, I'd also like to hear about | |
92 | anything in the Services user interface that seems awkward or unintuitive, | |
93 | whether new for 5.1 or present since previous versions. After over ten | |
94 | years of development, I know Services inside and out, so things that seem | |
95 | obvious to me may not be so to newcomers. If there are any questions you | |
96 | frequently get from new users, that probably means something needs to be | |
97 | changed, so let me know. | |
98 | ||
99 | Technical issues should be directed to the coding list, as always. In | |
100 | particular, if there are any issues with packaging Services for use with an | |
101 | operating system distribution, I'd like to hear about them so that they can | |
102 | be corrected. (I personally use a home-built Linux system, and as such I | |
103 | haven't kept close track of changes in how various OSes and distributions | |
104 | arrange their filesystems.) | |
105 | ||
106 | I realize that this "end-of-life" announcement for Services may come | |
107 | as a surprise to some, and for that I apologize. As I mentioned earlier, I | |
108 | will continue to support Services for some time to come (my current thought | |
109 | is for two to three years after the release of 5.1.0); however, I did want | |
110 | to provide advance warning of my future intentions. Thank you all for your | |
111 | support over the years. | |
112 | ||
113 | --Andrew Church | |
114 | <A HREF="http://lists.ircservices.za.net/mailman/listinfo/ircservices">achurch at achurch.org</A> | |
115 | <A HREF="http://achurch.org/">http://achurch.org/</A> | |
116 | ||
117 | ------------------------- | |
118 | What's New in version 5.1 | |
119 | ------------------------- | |
120 | Database handling, the one aspect of Services which has remained | |
121 | essentially unchanged since version 1.0, has finally undergone a fairly | |
122 | significant redesign. Rather than using specialized data load and save | |
123 | routines tailored for the core Services pseudoclients, Services now | |
124 | implements a generic database table system, which has the dual benefits of | |
125 | separating the data storage system from the rest of Services (allowing | |
126 | alternative storage methods to be implemented easily) and allowing third- | |
127 | party modules and extensions to create their own non-volatile databases | |
128 | without resorting to custom load/save routines. The default database file | |
129 | format has also been changed to be more flexible and error-resilient than | |
130 | the old format (which admittedly isn't saying much); see the "upgrading" | |
131 | section of the manual for instructions on switching your databases to the | |
132 | new format. | |
133 | ||
134 | The often-criticized channel memo system has also been redesigned for this | |
135 | version. Instead of storing channel memos with the channel, memos are now | |
136 | sent to the founder and all users on the channel with a particular access | |
137 | level (by default level 100, or SOP level). These memos are distinguished | |
138 | from ordinary memos by text that says "(for #channel)" when reading the | |
139 | memo. As a result of this change, users will be notified about new channel | |
140 | memos in the same way as ordinary user-to-user memos. | |
141 | ||
142 | NOTICE: When loading databases from version 5.0 or earlier, all channel | |
143 | memos will be deleted. | |
144 | ||
145 | Encryption support has also been improved. Encryption is no longer an | |
146 | all-or-nothing affair; the encryption method is stored with each password, | |
147 | so that enabling or disabling encryption will have no effect on passwords | |
148 | that were previously set. The "encryption/unix-crypt" module has been | |
149 | added, allowing the use of the Unix crypt() function to encrypt passwords. | |
150 | ||
151 | The NickServ and ChanServ SENDPASS commands added in version 5.0 have been | |
152 | removed in favor of the new NickServ REAUTH command. This command | |
153 | generates an authentication code which the user can use once to identify to | |
154 | their nickname in place of the password, and then change the password as | |
155 | needed. Channel passwords can always be changed by the founder after | |
156 | nickname identification, rendering ChanServ SENDPASS unnecessary. | |
157 | ||
158 | Long LIST/VIEW responses are now handled more cleanly. Except for NickServ | |
159 | ACCESS LIST (since nickname access lists are generally short) and MemoServ | |
160 | LIST (since memos are numbered), every list now includes an "end of list" | |
161 | message indicating both the number of entries displayed and the total | |
162 | number of entries in the list; the configuration directive ListMax, | |
163 | replacing NSListMax and CSListMax, sets the maximum number of entries | |
164 | displayed for any of these commands. It is also possible to skip a certain | |
165 | number of entries by adding a "+NNN" after the command, allowing all of the | |
166 | entries in a long list to be viewed bit by bit. | |
167 | ||
168 | At the development level, handling of module compilation has been improved, | |
169 | allowing third-party modules to be simply "dropped in" without requiring | |
170 | changes to Makefiles or other Services distribution files. An extension | |
171 | interface has been added to Services' multilingual support as well, | |
172 | allowing modules to add their own language strings and load their own | |
173 | language files. | |
174 | ||
175 | Other changes: | |
176 | + Command aliases can now be added for NickServ, ChanServ, and MemoServ | |
177 | commands via the NSAlias, CSAlias, and MSAlias directives. | |
178 | + Notices are now sent to the user when sending of a mail authentication | |
179 | code message fails. (However, errors after the message has been | |
180 | handed off to the mail server cannot be detected.) | |
181 | + A new configuration directive, RejectEmail, now allows selected E-mail | |
182 | addresses to be rejected by NickServ and ChanServ commands. | |
183 | + NickServ INFO will now indicate when a nickname's user is using a | |
184 | different linked nickname if the nickname group's PRIVATE option | |
185 | is not set. | |
186 | + NickServ now has a RESTOREMAIL command (in the nickserv/mail-auth | |
187 | module), which allows a user to restore their nickname's last | |
188 | authenticated E-mail address if, for example, SET EMAIL is used | |
189 | with an incorrect address. | |
190 | + NickServ SET/UNSET by Services administrators for others' nicknames is | |
191 | now done by putting a "!" before the nick to avoid ambiguity; for | |
192 | example, "SET !nick NOEXPIRE ON" instead of "SET nick NOEXPIRE ON". | |
193 | + ChanServ REGISTER and SET PASSWORD now check for and disallow easily | |
194 | guessable passwords. | |
195 | + ChanServ ACCESS now includes a LISTLEVEL subcommand to list access | |
196 | entries with a given level or within a given level range. | |
197 | + ChanServ AKICK and MemoServ IGNORE now support matching by IP address | |
198 | (on servers which support client IP address information). | |
199 | + ChanServ OP, VOICE, and similar commands can now be used with multiple | |
200 | nicknames. | |
201 | + MemoServ now has a RENUMBER command to remove "holes" in the memo | |
202 | number sequence. | |
203 | + MemoServ FORWARD now sends all selected memos in a single E-mail | |
204 | message, rather than sending each memo in a separate message. | |
205 | + OperServ AKILL and related commands now have a CHECK subcommand which | |
206 | can be used to find all masks that match a given user/hostname. | |
207 | + SQlines are no longer applied to IRC operators during Services startup | |
208 | or netjoins if the IRC protocol in use supports sending user modes | |
209 | with the NICK message. This includes the bahamut, hybrid, | |
210 | inspircd, monkey, ptlink, ratbox, solid-ircd, trircd, and unreal | |
211 | protocol modules. | |
212 | + The ignore system has been redesigned, and now keeps better track of | |
213 | how much load each user is putting on Services. The ignorance | |
214 | threshold can be fine-tuned via the configuration file. | |
215 | + A new "unsorted list" mode has been added to improve Services' | |
216 | performance on large networks. By giving the -no-sorted-list | |
217 | option to the configure script, Services will not try to keep | |
218 | nicknames and channels in alphabetical order; this means that | |
219 | commands such as NickServ LIST will no longer return nicknames in | |
220 | order, but Services will run significantly faster. | |
221 | + Support has been added for the InspIRCd, ircd-ratbox, and solid-ircd | |
222 | IRC servers. | |
223 | + Unreal's NICKCHARS protocol option, allowing non-ASCII characters in | |
224 | nicknames, is now supported. | |
225 | * ChanServ DROP now behaves like NickServ DROP: dropping a channel now | |
226 | requires the channel password to be entered with the DROP command, | |
227 | and DROPCHAN has been added as a separate command for Services | |
228 | administrators to drop arbitrary channels. | |
229 | * The ChanServ ACCESS, XOP, and AKICK commands no longer use entry | |
230 | numbers; the DEL and LIST subcommands now work with nicknames | |
231 | (hostmasks for the AKICK command) only. | |
232 | * The binary distributions (RPM and Debian packages) now install into | |
233 | /opt/ircservices and /var/opt/ircservices, rather than /usr/sbin | |
234 | and /usr/lib/ircservices. | |
235 | * Tab characters are no longer used (or allowed) in the source code. | |
236 | - The deprecated nickserv/oldlink module, which provided support for the | |
237 | format of the LINK command used in version 4 of Services, has been | |
238 | removed. | |
239 | - Support for "modeless channels", with names of the form "+name", has | |
240 | been removed. (Support for registering such channels was removed | |
241 | in version 5.0.0; this version removes the special handling for | |
242 | such channels in other parts of the program.) | |
243 | - Support for the "channel owner" mode present in the PTlink (+a), | |
244 | trircd (+u), and Unreal (+q) IRC servers has been removed, as there | |
245 | are too many differing opinions on its proper use. | |
246 | - Language support for Italian and Portuguese has been removed, due to | |
247 | the lack of volunteers to maintain them. | |
248 | - Support for old versions of GCC (anything before GCC 3.2) has been | |
249 | removed. | |
250 | Configuration file changes: | |
251 | + IncludeFile has been added to allow configuration directives to be | |
252 | split up into multiple files, and may be used in both | |
253 | ircservices.conf and modules.conf. | |
254 | + LoadLanguageText (ircservices.conf) has been added to allow replacement | |
255 | of Services text strings at runtime. | |
256 | + RejectEmail (ircservices.conf) has been added to allow rejection of | |
257 | selected E-mail addresses. | |
258 | + NSAlias (module nickserv/main), CSAlias (module chanserv/main), and | |
259 | MSAlias (module memoserv/main) have been added to allow creation of | |
260 | command aliases. | |
261 | + NSSetEmailDelay (module nickserv/main) has been added to enforce a | |
262 | delay between consecutive uses of the SET EMAIL command, thereby | |
263 | reducing the potential for sending mailbombs. | |
264 | + CSDefModeLock (module chanserv/main) has been added to allow the | |
265 | default mode lock for newly registered channels to be changed. | |
266 | + CSSkipModeRCheck (module chanserv/main) has been added to allow the | |
267 | check of a nickname's registration status at channel join time | |
268 | (used to kick unregistered nicknames from channels locked +R) to | |
269 | be skipped. | |
270 | + MSExpireDelay (module memoserv/main) has been added to allow memo | |
271 | expiration to be delayed until a certain time after the memo is | |
272 | first read. | |
273 | + MaxMessages (module mail/main) has been added to allow a limit to be | |
274 | placed on the total number of messages in transit. | |
275 | * ListMax (ircservices.conf) has been added in place of NSListMax and | |
276 | CSListMask to set a limit on the number of entries displayed for | |
277 | all LIST-like commands. | |
278 | * WallAdminPrivs (ircservices.conf) has been added in place of | |
279 | WallGetpass and WallSetpass to cause a WALLOPS/GLOBOPS to be sent | |
280 | on all NickServ and ChanServ commands that use Services | |
281 | administrator privileges. | |
282 | * The database name configuration directives (NickServDB, ChanServDB, | |
283 | etc.) have been moved from the various pseudoclient module sections | |
284 | to the database/version4 module section, and now explicitly specify | |
285 | filenames. | |
286 | - The nickserv/sendpass and chanserv/sendpass modules (and therefore | |
287 | their respective configuration sections) have been removed. | |
288 | - CSAutokickReason (module chanserv/main) has been removed, as the | |
289 | built-in reason prefix "AKICK by <nick>" makes it unnecessary. | |
290 | - MSExpireUnread (module memoserv/main) has been removed, since it | |
291 | results in silent data loss. | |
292 | - MSNotifyAll (module memoserv/main) has been removed, since it is | |
293 | required for channel memos. MemoServ will now always behave as if | |
294 | MSNotifyAll was set. | |
295 | - MaxSockets (module mail/smtp) has been removed, since MaxMessages now | |
296 | performs the same function. | |
297 | </PRE> | |
298 | ||
299 | ||
300 | ||
301 | ||
302 | ||
303 | ||
304 | <!--endarticle--> | |
305 | <HR> | |
306 | <P><UL> | |
307 | <!--threads--> | |
308 | <LI>Previous message: <A HREF="005265.html">[IRCServices] Feature request | |
309 | </A></li> | |
310 | <LI>Next message: <A HREF="005274.html">[IRCServices] Services 5.1pre0 released | |
311 | </A></li> | |
312 | <LI> <B>Messages sorted by:</B> | |
313 | <a href="date.html#5262">[ date ]</a> | |
314 | <a href="thread.html#5262">[ thread ]</a> | |
315 | <a href="subject.html#5262">[ subject ]</a> | |
316 | <a href="author.html#5262">[ author ]</a> | |
317 | </LI> | |
318 | </UL> | |
319 | ||
320 | </body></html> |