Home of the Fusebox-core-L mailing list

This is the home page for the Fusebox-core-L mailing list and will be used by the core team to document the processes and plans for the core files.

Fusebox 5.5

The next major release of Fusebox will be 5.5.0. Discussion is active on the fusebox5 mailing list.

We were aiming for a Public Beta in the CFUNITED timeframe (end of June 2007) but the 5.5 release is turning out to be more ambitious than we originally envisaged and to we are currently locking down Alpha 2 (as of August 14th). The framework vision statement should guide everything we do to the core files (and, yes, the vision statement needs plenty of refinement at the moment!). In addition, each release typically has two or three themes that provide focus for that phase of development.

Basic Principles

Fusebox is a very stable, mature application framework. The basic (XML) syntax hasn't changed much since Fusebox 4 was introduced almost four years ago and pretty much every single Fusebox 4.0 and 4.1 application still runs unchanged on Fusebox 5.0 and Fusebox 5.1.

Backward compatibility is extremely important to protect everyone's investment in Fusebox so it is a core principle that Fusebox 5.5 will also run all those existing applications unchanged.

Additions and/or changes to the core XML language should be rare and considered extremely carefully. Adding verbs or even attributes makes Fusebox more complex and harder to learn (as well as making the core files harder to maintain).

Themes for Fusebox 5.5

Fusebox 5.5 has the following two themes:

• Simplify. Remove barriers. Make it easier for newbies. Make building applications faster by favoring convention over configuration.
• Extend through extensibility. Provide new functionality outside the core. Add plugins, lexicons, even standardized circuits.

Simplify - Remove barriers

We want to lower the barrier to entry by introducing some default conventions that help remove the need for XML configuration. For example, in the absence of fusebox.xml / circuit.xml files, a request for fuseaction=home.welcome should still understand a circuit called "home" and a fuseaction called "welcome" and be able to "do the right thing". Determining the right conventions is not trivial - we might look to Ruby on Rails, for example.

Extend through extensibility

We want to keep the core stable, i.e., don't add new features directly to the core, but leverage the extensibility points (plugins, lexicons) to provide optional packages of additional functionality. The Fusebox 5.1 skeleton hints at this with additional lexicons. Recent commits include an assertions plugin and lexicons for Transfer and Reactor. Fusebox 5.5 could then become a suite of official downloads, perhaps incorporating some sort of community-contributed "Fusebox Exchange". Scaffolding is a specific example of something that has been discussed as a possible extension for Fusebox 5.5.

Important Links

• Fusebox framework vision statement - work in progress
• Fusebox core files architecture and principles
• Roadmap and Tickets
• Browse the framework source code - see below for information about Subversion repository
• Open a new ticket

Important Processes

All core file changes are driven by tickets. Tickets can cover defects (bugs), including backward compatibility issues, or enhancements. Some tickets are already open for Fusebox 5.5.

Almost all core file changes need discussion and consensus before being implemented. Occasionally a core file change is non-controversial and obvious (backward compatibility bugs, for example).

Experimental core file changes happen on a development branch - see Subversion section below - and are later merged into the trunk which is kept stable. Simple bug fixes etc can occur directly on the trunk.

Becoming a committer: right now, only Sean Corfield and Mike Ritchie have commit access on the framework. Kevin Roche and Peter Bell have commit on the scaffolding extensions tree. We anticipate people will submit changes to us for review - preferably as SVN patch files! - and we will approve / reject the change (and commit it if approved). This is done to keep the core files as stable as possible, to maintain the integrity of the architecture and to keep things consistent. Over time, we anticipate "promoting" some of you to committer status if you are a frequent contributor of patches and those patches are of consistently high quality.

Subversion

Fusebox is maintained using a source code control system called Subversion. If you aren't using source code control, you should be and, unless you have a good reason to use a different system, you should be using Subversion. If you want to work on the core files, you must have Subversion!

Suggested Subversion clients

• Subclipse - If you're using Eclipse / CFEclipse, you should install Subclipse.
• SmartSVN - Is a stand alone application for managing subversion working copyies and repositories
• TortoiseSVN - Is an application which integrates subversion control into the windows explorer
• SCPlugin - Is much like ToroiseSVN but for Mac OS X
• Subversion - Subversion comes with a command line client which is the most fully featured (non-gui) application available
• SVNKit - The Java library underlying Subclipse and SmartSVN that comes with a command line client. Useful if you need command line access but can't install the official Subversion client (because of APR conflicts, for example).

TODO: add other suggestions!

Setting up Subversion for the Fusebox repository

You can see a short video with instructions on checking out the Fusebox Core Files from the Subversion repository here

The repository structure

The Subversion repository has the following structure:

• /framework - this is where the ColdFusion core files are kept
  • /branches
    • /dev - this is where experimental - unstable - core file development is checked in: the (very) Bleeding Edge Release (BER)
  • /tags - this is where all released versions are tagged
    • /fusebox500
    • /fusebox510
    • ...
  • /trunk - this is where stable core file development is checked in or merged in from the dev branch: this is the (stable) BER
• /phpframework - this is where the PHP core files are kept
  • /branches
  • /tags - this is where all released versions are tagged
    • /fusebox500
    • ...
  • /trunk - this is where stable core file development is checked in or merged in from any dev branch (there isn't one right now): this is the (stable) BER
• /website - this is where the main infrastructure of the website is kept
  • /trunk - ongoing website development

Who's Who?

Team Fusebox coordinators:

• Sean Corfield - project lead ColdFusion core
• Mike Ritchie - project lead PHP core
• Kevin Roche - project lead scaffolding (ColdFusion)
• Peter Bell - contributor scaffolding (ColdFusion)