Red5 Backwards Compatibility Report

Update Period

08-JAN-2009 to 22-JAN-2009

Major New Features

Feature What it Means
org.red5.server.Bootstrap is now the default launcher .jar files living in $RED5_HOME/lib are automatically now in your classpath, along with any jar files in your WEB-INF/lib directory, and the right things happen.
Red5 Continuous Build Server now publishes “stable builds”:
Java 1.5
Java 1.6
Every Red5 build that passes all unit tests and system tests gets published here. To use a build, select the one you want (example) and then update your local copy of Red5 to the same SVN revision numbers.  We’ll work on making a downloadable .zip file for a future release.

Changes With Compatibility Impacts

Revision Description
New Xerces-J libraries (XML parsing)
Fixed “due to too much inactivity” closing live clients bug.
R3379 and red5.bat now use Bootstrap as the main class. This means that org.red5.server.Standalone is no longer used. This should mean that .jar files in your WEB-INF/lib directory and in the $RED5_HOME/lib directory are correctly loaded, and your apps can load any class in your WEB-INF/lib or the $RED5_HOME/lib directory.

Way to go Paul!

Also, you can now have copies of a jar that is in $RED5_HOME/lib as well and Red5 will correctly use your jar file for your app.

Security manager is now disabled by default as it causes problems with the Red5 selftest.
“ant server” should work again. Conf dir was missing from server target.
Added latest spring security libs.
R3395 Fixed APPSERVER-310; The MP3 Reader should work once more.
R3397 Modified the policy in hopes that anyone running a SecurityManager will not run into problems originating from Red5 itself or shared/common libraries.
R3408 Fixed on Linux and Windows MSYS machines. They should work even if you install Red5 in a directory with spaces in the name.

More Details

For details on these and all other changes to red5:

Previous Reports

You can find the last report here.

What Is This Report

Red5 is under active development and as such APIs and the implementation are subject to change at any time.

To help with that problem and as a service to the Red5 team, every two weeks Xuggle publishes updates giving a summary of major changes since the last report that MAY require changes to your existing Red5 applications.

Other changes may have been made as well, but we do not expect them to cause backwards compatibility issues.

See here for more background.


One Response to Red5 Backwards Compatibility Report

  1. Alexander Bethke says:

    Thanks for the report. In my opinion it really helps making Red5 development more transparent.

    Regards, Alex

%d bloggers like this: