Supported Platforms

Here's the list of platforms we try to support today.

And yes Virginia, that means to do a release, you need to build your final candidate on each of those OSes. You can substitute Vista for XP for now (but not the other way around), but expect that to change once someone ponies up an XP build box.

You should try to write code that SHOULD work on all OSes and architectures that Java is supported on (e.g. Sparc, ARM, etc), but we're ownly on the hook for the above list right now.

We don't try to support Kaffe, IBM's JVM, or any other JVM, but again, we try not to write code that stops that.

Version Number Format

Xuggle version numbers are of the form:

       {library}.{major}.{minor}[.revision][.description]

For example:

xuggle-xuggler.1.15.137.rc1

xuggle-utils.2.15.35.rc1

xuggle-xuggler-red5.1.1.1129

xuggle-xuggle-red5.1.1.1140

xuggler.3.0

When To Change Version Numbers

Try not to do major version increments that don't add major new features since users of the library will have to actively choose to upgrade to use it; most people using ivy will take minor version increments without much hesitation. None the less, here are some guidelines for what counts as a major revision. This list is not final, and the actual decision should be made by the release team (currently Art and Robert).

Major Version Increments

Things that should almost definitely cause a major version increment

• Changing a C++ public header file to reorder, remove or change a class signature or method signature; may also be necessary even if you add a new member (depending on the class). if you're not sure the header change should do a major increment change, increment major anyway.
• Major new feature added that breaks backwards compatibility (although you should try to ever break backwards compatibility).
• Adding a new feature that is 100% backwards compatible, but required adding native code.
• Removing a Java class or Interface, or a method from a Java class or Interface.
• Basically, if you f*ck with native code, be prepared to bump a major version number. Trust me on this.

Minor Version Increments

Things that should almost definitely cause a minor version increment

• Adding a new Java class, interface, or method
• Adding a new feature that is 100% backwards compatibile, but did not require changing native code.

Revision Increments

• Fixing a bug in a C++ file or Java file, but no changes to class, interface or method signatures
• Documentation updates

Release Checklist

This is a checklist of the steps one should take when bundling a new release of a xuggle library.

• Identify proposed good build from the continuous build server.
• Announce tree is frozen
• Document proposed SVN revision (from current), and SVN revision of any Externals in release notes.
• Make sure revision numbers in configure.ac, build.xml, and any windows installers are correct
• Uninstall old versions of library on all supported OS
• Install candidate on each supported OS
• Do the appropriate library post-install test (e.g. for xuggler, java -jar xuggle-xuggler.jar test/fixtures/testfile.flv --acodec libmp3lame /tmp/out.flv)
• Make sure that demos still work.
• Upload new jars for release to repository
• Upload installers and source bundle to Amazon S3
• Make sure uploaded files have read permission
• Increment major and/or minor revision numbers in tip of tree (must change both configure.ac and build.xml).
• Re-run autotools if configure.ac was changed
• Update any downloads web pages with new release
• Update blog.xuggle.com
• Send message to xuggler-users@groups.google.com

Source Code Conventions

Here's the source code conventions we try to use. Please keep using them.

• 2 space indention; no tabs
• Method and variable names should have descriptive names and can be any length < 255 characters.
• Member variables of classes should begin with "m": e.g. int myMemberVariable;
• Class names start with a Capital letter: e.g. class MyClass
• Method names start with a lower case letter: e.g. void myMethod()
• Braces should get their own line, except for variable initializers.
• You should use Packages (in Java) or Namepsaces (in C++) for any objects you create. Packages should be under "com.xuggle"; Namespaces should be under "com::xuggle".
• Static methods SHOULD think carefully about creating any long-term caches and objects; they won't be cleaned up by garbage collectors.
• All objects exposed from C++ to other languages MUST derive from com.xuggle.ferry.RefCounted and use reference counted memory semantics.
• All methods and classes must have Javadoc style documentation.
• Unix file-format (i.e. \n line endings, not \r\n).
• Reformatting checkins (to remove bad formatted) are allowed, but ONLY if no other changes are in that check-in
• You break the build you fix it. No exceptions (or we back the change out).
• No check-ins without having someone else review your code; No exceptions.
• Two drink minimum for any build system changes

• About
• Downloads
• Demos
• Licensing
• Documentation
• Support
• Status