It should come as no suprise to folks that we've been hard at work on what will become RT 4.0.
We've been working hard to overhaul the entire codebase. The current version of the web interface is only 10,000 lines of HTML shorter (118kloc down from 128kloc), but the core libraries have shrunk from 68kloc of code to 54kloc.
At the same time, we've moved RT from its own homegrown application framework to Jifty, Best Practical's next-generation web application platform. Jifty brings with it all sorts of new features which make it easier to build out web services and web applications with less code and easier support for modern Web 2.0 features.
If you download the RT 3.999 development branch today, you'll find a few major new features. The most visible of those is "Status schemas." In RT 4, you can define directed graphs of ticket states and valid transitions between those states. You can associate one or more queue with any status schema. At its simplest, this means that you can now freely add or remove statuses from your RT instance through the web interface. If you want to get a bit fancier, you can specify that "new" tickets can move only to "open" or "rejected" and that "open" tickets can only move to the "testing" or "rejected" states. This makes it easier than ever to adapt RT to your existing process and workflow.
Under the hood, we've begun to generalize other parts of RT. While role groups are still limited to "Requestor", "Cc" and "AdminCc", we've mostly completed work that will allow you to define custom role groups. (Exposing that functionality isn't currently slated for RT 4.0)
There are a few fairly major projects in progress which we're currently planning for RT 4.0:
- Most application configuration will move into the database, making it easier for RT administrators to fully manage RT using the web interface.
- TicketSQL has been extended as 'tisql', a new, more powerful query language which will be available internally for all objects in RT, not just tickets.
- Scrips are being replaced with a new workflow engine codenamed 'Lorzy'. Lorzy makes it possible to build out much more complex rules than Scrips' simple "If __ Then __" conditionals. Under the hood, Lorzy is a fully sandboxable lisp-like functional minilanguage with named, typed arguments and the ability to detect runaway rules and limit individual rules by actor. In the future, we hope to also expose Lorzy as a user-level scripting engine for RT.
- Date and Time rationalization - We've been ripping out RT's old and fairly adhoc implementations of various bits of date and time and replacing them with a shiny, new implementation based around Perl's DateTime suite.
There are a dozen other projects we want to undertake - We're going to try to hold out so we have something cool to show for 4.2, 4.4 and beyond.
We have a few additional bits of backward-compatibility we want to break before declaring something as a 4.0 "beta" that we'd actually like folks to test in production. We're not there yet. I'll tell you as soon as we get there.
4.0 is a major new release of RT. Like the transition from RT 2.0 to 3.0, 4.0 represents a major break in backwards compatibility with older versions of RT. When you look under the hood in RT 4, you'll see that the entire API has been overhauled to match more common Perl style guidelines. The most obvious change is that the API has been rationalized to lower_case_style from the previous CamelCaseStyle, but there are numerous other changes throughout the product's internals. We've written more RT extensions than anyone out there (as far as I know) and we're very, very aware of just how painful a major API change is. We have the beginnings of tools and guidelines to help you make the transition with as little pain as possible.
It should come as no surprise to you that I'm not announcing a release date for RT 4.0.0 today, nor will I be doing so in the immediate future. We have a _long_ way to go before RT 4 will be the recommended version of RT for a production or evaluation deployment. Even once that happens, Rest assured that we'll continue to support RT 3.x for a good long time. Best Practical's business is built on helping our users make good use of RT and our other products -- We're not about to cut off those of you using RT 3 in production.
Best,
Jesse
RT4 Release MicroFAQ
- Clean up code that you think needs cleanup.
- Add or improve documentation. Find bugs.
- Fix bugs.
Is there anything a end-user/admin can do to help expedite this process?
Posted by: MJ | March 27, 2009 at 03:18 PM
@MJ - Right now, there's very little an end-user can do to help make RT4 get done faster other than helping folks out on rt-users so that core hackers can keep their noses closer to the grindstone.
Once we get a first alpha version out, trying valiantly to install it and reporting back every problem no matter how small will be a huge help.
Posted by: Jesse | March 27, 2009 at 04:20 PM
Will the full REST API be implemented, or will that be left for 4.2, 4.4?
Posted by: Bakafish | March 30, 2009 at 11:31 PM
@bakafish - Jifty includes automatic, comprehensive RESTian interfaces for application models. So right out of the gate, RT4 should have much more comprehensive REST support.
Posted by: Jesse | April 02, 2009 at 06:16 PM
We are looking into installing new version of RT from 3.6.1. Would you recommend to wait for 4.0 or go ahead with 3.8? Just wondering when do you plan to make official release on 4.0.
Posted by: Scott | May 28, 2009 at 01:54 AM
@Scott,
Never trust a vendor promising a cool new version of software "soon". We'll be supporting RT 3.8 for a good long time. Install 3.8 today. Upgrade to 4.0 when it's ready.
Posted by: Jesse | May 29, 2009 at 04:40 PM
Any chance of a further update? Its been 6 months
Posted by: Mark | November 04, 2009 at 11:00 PM
Still with Mason or moved to some other framework?
Posted by: Answerguy | January 21, 2010 at 08:22 AM
I'm really keen to find out how the development is going. The activity on github seems slow. Any chance on a comment?
Posted by: dave ekmpe | March 22, 2010 at 06:51 PM