News

Hey folks,

I’ve been receiving a number of questions about why Form Tools 2 is still in beta and when a final, stable release will be out. Many people are clearly concerned about getting on board with a script that isn’t polished – a very understandable concern! Well, I’ve been rethinking my position these last couple of days and thought I’d write a post about what’s going to change.

As it stands today

The “beta” label has nothing to do with the stability of the script – in fact, I’d regard it as having been stable for many, many months now. Actually, my original plan was to leave Form Tools 2 in beta indefinitely. I like the term “beta” for a number of reasons and thought that Google’s model of leaving scripts in perpetual beta fit well for what I was trying to do.

Consider this: no software is every truly complete or perfected; all non-trivial scripts have bugs. This is just the nature of the beast. In light of this, it seemed dishonest NOT to label Form Tools 2 as a beta! Scripts that proudly proclaim “v1.0″ imply a polished, bug-free product. That’s never the case – I didn’t want to give a false sense of the state of the script.

But the way I’ve implemented it is problematic. Unlike other scripts, Form Tools versions are released in a single thread: everyone get the same code, like it or lump it – and they’re all labeled “beta”.

Problems with this approach

1. People think “beta” means unfinished and shy away from using the script.
2. Adding in new features adds it directly to the trunk. This is great because it ensures everyone’s up to date, but it’s also problematic because some changes have higher impact and risk. Generally people favour stability over new features.
3. Component dependencies. There are increasing more modules, all of which rely on the Core. As the core changes, the modules can be affected. Up to this point, the dependencies have been few and far between, but it’s going to escalate. Mapping a particular dependency for module A to beta “2.0.0-beta-20090116″ makes less sense than mapping it to “2.0.1″.

What’s going to change

Basically I’m going to be moving to a more typical release model – retaining the agile approach, just tweaking it a bit. There will still be a single branch of the code (the trunk), but the main download files will ALWAYS be “standard release” snapshots – 2.0.0, 2.0.1 etc. You won’t see any more numbering schemes like “2.0.0-beta-20090116″ from the standard download files – this will be both for the core, modules and API. Upgrading *will* provide you with the option of downloading beta as well as standard releases, but they’ll be hidden by default.

For people interested in the latest cool stuff coming out of beta, they can go to the Custom Build page. That script will list all beta versions as well as the standard release.

The “beta” term will now be more intuitive to a lot of people, I think. It will contain newer, less tested code – for most people, they won’t care: they’ll just get the standard release and be done with it.

Also, I’ll be updating the custom build and upgrade scripts to visually display dependencies. Now THAT’s going to be fun!

Coming soon…

In the short term, I’ll be releasing one more update to Form Tools tomorrow or the day after: it will contain a new feature to allow you to pinpoint multiple email fields in your forms for use in the email templates. This will be the final “beta”. I’ll then make that release the final 2.0.0 release.

That’s pretty much it. Part of what prompted this whole thing was that I want to add two new larger features to the core: a scheduler and an error logging system, and didn’t want to create a new branch… but that’s another story. More on that later…

- Ben