The JSPWiki development team thinks 2.6 is the best release yet. Here's a quick summary of the most important enhancements. For the complete and growing documentation, go to [http://doc.jspwiki.org/2.6].

!Core
* __Servlet 2.4 container support__. JSPWiki 2.6 requires a JEE servlet 2.4-compatible container, such as Apache Tomcat 5.5 or higher.
* __Internationalization support__. JSPWiki's JSPs are now fully internationalized. The languages supported out-of-the-box are English, Finnish, German, and Spanish. In the deployed WAR file, localization files for templates are stored in WEB-INF/i18n/templates. "Core" class localization files are in WEB-INF/i18n.
* __Approval workflow for page edits__. JSPWiki 2.6 implements moderated page changes. The name of the user, role or group that approves page changes is contained in {{jspwiki.properties}} under the property {{jspwiki.approver.workflow.saveWikiPage}}. If not supplied (the default), page changes are performed without requiring approval.
* __Support for container-managed e-mail factories__. ~MailUtil gains the ability to use container-managed JNDI JavaMail session factories, in addition to the standalone factory configured via {{jspwiki.properties}}. JNDI is now the preferred method of obtaining mail sessions, and will always be attempted first before falling back to the stand-alone method.  For configuration hints see [JNDI Mail Configuration]
* __Goodbye wikinames__. User profile JSPs no longer request a distinct wiki name when a user registers. The wiki name is now computed automatically; it is the user name without any whitespace. This change should make registration even easier.
* __Snappy search__. JSPWiki now boasts JSON-assisted searches, for instant gratification.
* __XHTML compliance__. All pages are XHTML compliant.
* __Welcome, spaces__. JSPWiki now supports whitespace in page names, so you no longer have to ~WriteYourPagesLikeThis.
* __Improved WYSIWYG editor support__. FCKeditor is now a viable editor option. You will need to install FCKeditor separately though; however, it should a quick and simple procedure.


!Templates and JSPs
* __New default template__. Dirk Frederickx's excellent Brushed template serves as the basis for JSPWiki 2.6's new default template. It's full of AJAX goodness and looks great.
* __Tag enhancements__. <PermissionTag> now allows a list of permissions just like <CheckRequestContextTag>, as well as negative permissions.
* __JavaScript compression__. The WAR includes compressed jspwiki-edit.js, jspwiki-common.js and jspwiki-prefs.js files, using the Rhino library.  This should bring in considerable savings to bandwidth and give better response.
* __JSP 2.0 Tags__. All JSP taglib declarations were changed to use JSP 2.0-compatible tags. We also upgraded jstl.jar and standard.jar to JSTL 1.1 versions. Note: if you are a template developer, you should change your taglib declarations as follows:'s
{{{New:
   <%@ taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt" %>
   <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>

Old:
   <%@ taglib uri="http://java.sun.com/jstl/fmt" prefix="fmt" %>
   <%@ taglib uri="http://java.sun.com/jstl/core" prefix="c" %>}}}

!Security
A big priority for JSPWiki 2.6 was the simplification of the security configuration. In particular, users wanted us to make it easier to configure security policies, particularly in multi-wiki configurations. Here are a few of the most important changes:

* __Local security policies for each wiki__. In JSPWiki 2.5, we implemented security policies by overriding the JVM-wide security with our own. In cases where a security policy was already installed by the container, this was causing JSPWiki to fail. To make things Just Work, we've eliminated the need to set a JVM-wide security policy. Instead, we install a "local policy" that is always read from WEB-INF/jspwiki.policy. If you have a JVM-wide policy, the local policy will supplement it. The practical upshot of this change is that the most common configuration challenge that most first-time admins face (why won't any pages display?) is gone, and gone forever. No more fiddling with the java.security.policy property! The syntax for the local policy is exactly the same as in previous versions.
* __JAAS LoginModule enhancements__. JSPWiki now allows full use of non-JSPWiki supplied JAAS LoginModules in the JSPWiki-custom configuration. Previously, we considered a user to be authenticated only if a {{LoginModule}} had added {{Role.AUTHENTICATED}} to the Subject's principal set. This is clearly unreasonable for LoginModules that have no knowledge of JSPWiki, such as Sun's supplied modules or third-party modules used for LDAP authentication. Now, we consider a user authenticated if they are not anonymous and not asserted, and we lazily add {{Role.AUTHENTICATED}} in these cases, after login.
* __Simpler default security policy__. The security policy file has been simplified to remove redundant grants that don't vary across roles. It should be simpler to read and understand.
*__E-mail authentication__. Configuration options for e-mail services, used for things like password resets, includes authentication support, so that you can use mail servers that require an account (the OpenRelay issue...). You now also can indicate a different smtp port. 
* __Spam controls__. There's a new SpamLog which can be used to track all changes; accepts and rejects. SpamFilter adds Captcha recognition, if we suspect you to be a spammer. SpamFilter captcha is user-settable.  Possible options are "none" and "asirra".
* __Permissions changes__. With PagePermissions, the {{rename}} permission no longer implies {{modify}} (or {{upload}}). This will allow separation of uploading attachments from page edit/rename actions.
* __Approval workflow for user profile creation__. New profiles can be routed for approval before they become active. The name of the user, role or group that approves new profiles is contained in {{jspwiki.properties}} under the property {{jspwiki.approver.workflow.createUserProfile}}. If not supplied (the default), user profiles are created without requiring approval. Profile registrations automatically trigger an e-mail confirmation to the user, if an e-mail address was supplied.
* __Profile login/user name changes__. Users can change login names and user names ("full names") after registration.
* __Weblog security enhancements__. WeblogPlugin now considers ACLs - if the user does not have view permission on an entry, it's ignored on display.
* __No more JAR signing__. We have eliminated the need to sign JSPWiki JARs for 95% of most users' deployments. Now, the only case where you need to sign them is when you wish to create a JVM-wide, consolidated security policy. We have retained an Ant target "signjar" for that purpose. If you are upgrading from an earlier version of JSPWiki and are using a customized policy, however, you ''must'' remove any "signedBy jspwiki" and "keystore" references, otherwise JSPWiki might act oddly.
* __Tighter defaults__. {{SecurityConfig.jsp}} now ships off by default, but can be enabled by setting {{jspwiki-x.securityconfig.enable=true}}.  The page also has instructions on how to accomplish that, when you try to access it.
* __Remember me__.  Now, by enabling the CookieAuthenticationLoginModule in your JAAS file, you can keep your users logged in for days without the need to write in your username and password every time you visit the site!

!Developer
Under the hood, JSPWiki adds quite a few classes, packages and features for developers. Here are a few of the highlights:
* __We hate bugs less than before__. JSPWiki now has a real bug database, at the [Apache JIRA site|https://issues.apache.org/jira/browse/JSPWIKI]
* __Workflow package__. JSPWiki 2.6 adds a significant new package for modeling workflow operations (com.ecyrd.jspwiki.workflow). This package allows arbitrary combinations of "steps" to be modeled, with support for unlimited branching and support for human intervention. The core class is the Workflow class. Workflows are composed of Steps, which can be Tasks (which run uninterrupted) and Decisions (which require input from named Principals -- users, roles or groups). Page edits and profile creation approvals both use this package. 
* __i18n__. In the trunk, {{etc/i18n}} contains internationalization files.
* __Web unit test scripts__. Ant build script for webtests is now much smarter. Web tests now perform a "pre-flight" check to make sure preconditions are satisfied before launching. If you've wanted to run web tests before but "couldn't get them working," the new script should set things right.
* __New web unit test tools__. We ripped and replaced the old web unit test tool (JWebUnit) and replaced it with Selenium. Web tests are yet not at parity with old (failing) JWebUnit tests, but they are pretty good for a start. We removed all traces of JMeter, HttpUnit and JWebUnit, and re-based Selenium tests to {{tests/etc/selenium/tests}}. If you want to try developing your own web tests, check out Selenium IDE, a FireFox plugin that records user actions and generates tests scripts. 
* __Administration UI__.  This feature is still experimental, but you can do some of the basic maintenance tasks, such as user maintenance, using a web UI by going to admin/Admin.jsp.

!Bug fixes

Of course, every release of JSPWiki fixes a number of issues.  Here's the list of the issues which we have fixed in this release:

* [JIRA tracker, issues fixed in 2.6.0|https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732&styleName=Html&version=12312828]

!Compatibility notes

* 2.6 has a new PageFilter interface definition, so any 2.4-compliant PageFilter MUST be recompiled for 2.6 (please see the javadoc).
* Templates, in general, should work.  However, some very advanced Javascript templates (read BrushedTemplate) won't work.  But don't worry, the new default template is based on brushed, and it's got loads of goodies even BrushedTemplate does not have!
* Plugins should work without modification