If you follow our lists or forums, read our blog, or get this newsletter you can't have failed to notice that lately, there has been a positive flurry of new releases. 6.5, 6.6, 6.7(see more on this upcoming release below), and now 7.0, all appearing not just in rapid succession but concurrently. What are we to make of this? Why so many, so fast, and which should you be using?

Multi-threaded Development
The reason that we are seeing concurrent releases, or even for example, 7.0 going into testing before 6.7 is out, is that we now have a large enough team of programmers inhouse to be able to work on separate feature sets concurrently. So we have had one team working on 6.5/6.6 and bringing you all the new graphics architecture, resolution independence, automatic scaling for mobile (6.5) and desktop (6.6). Another team has been working on Unicode and everything that goes with it in version 7. And yet another group has been tasked with 6.7 and bringing you Cocoa, a reworked revBrowser and some other goodies I'm about to tell you about.

This mode of development lets us bring you new features as quickly as possible, and offers the optimal workflow for us. Not having major features in the same flow also means that if one project is overrunning, the others don't get held up by it. Of course, as soon as we get each feature set stable, we want to get it into your hands for testing. Which means that right now, you are spoilt for choice.

Fusion
All these branches will be fused into one coherent whole by the time each gets to its final release stage. So 7.0 gm will also incorporate resolution independence and Cocoa support. The numbering indicates the hierarchy, so 6.7 will not have unicode, but 7.0 will have Cocoa.

Name Your Baby

A word about our naming conventions. A final, stable release is a GM - Gold Master - and you will see it in your account as just the version number, eg 6.6.0, with no letters after it. An early test release will have the letters DP after the version number, meaning Developer Preview. This is a feature incomplete and probably buggy release, which is available for testing to assist us to fix all those issues before we get to final. A later test release will have the letters RC after it, meaning Release Candidate. It will be feature complete, and most of the major issues should have been resolved. It is still not recommended for production work, although you may get away with it.

What To Use?

For production work, you should use the last stable GM release. This is currently 6.6.0. If you are feeling brave, and you really really need a feature in an upcoming release, you could use a Release Candidate. If you use a Developer Preview for production work, bad things can happen. In a worst case scenario, a proposed feature could even be withdrawn from the final release, if it proved too problematic for some reason. Developer Previews are provided so that you get some foreknowledge of what is coming, and we all get a stable tested release at the end of the process.

Your Release Preferences

Not everyone wants to test every release we put out. We get that. There's a lot of new stuff coming out and you have work to do. If you don't want to get, for example, Developer Previews, you can turn this off in your LiveCode Preferences. Go to the Preferences panel available under your "LiveCode" menu, and select "updates". You'll see this:

I know. I just told you about developer previews and release candidates, and they are not listed here. I'll translate for you... So, stable releases = GM releases. Mainenance releases = a GM release that is purely a bug fix release. It will have a X.0.X number so for example 6.5 was the major release, 6.5.2 was a maintenance release. Beta releases equate to Release Candidates. Development releases means Developer Previews. Just check the boxes for the releases you want to see.

The Exception that Proves the Rule

Normally, every new release is pushed out by our release process to the automatic updater, and LiveCode will prompt you to download it (depending on how you've set your preferences). 7.0 dp 1 flouts this rule. We have not enabled it via the updater. To get it, you have to actively go to the downloads page and download it. The reason for this is that 7.0 represents such a major leap forward that at this early testing stage we wanted to make sure that only those people who really wanted to test it and knew what they were getting were downloading it. Accidental updating could result in lost work, as the file format has changed.

The Good Stuff

I promised you some inside info about 6.7 at the top of this article. The exciting news is, this is due to go into public developer preview testing any day now, and it will bring Cocoa compliance, a brand new revBrowser experience and substantial improvements to in-app purchasing, adding support for Amazon and Samsung stores.

Moving to Cocoa from Carbon on Mac will bring benefits:

• You will be able to submit LiveCode apps to the Mac App Store again
• The look and feel on Mac will become subtly more native
• Ultimately it allows us to move to 64bit support

In 6.7 dp 1 revBrowser has been updated. The main upshot of this is that the browser is now part of the host window and as such works correctly regardless of the type of window (dialog, palette, document etc). In addition a new browser component based on CEF (Chromium Embedded Framework) has been added. This new browser allows for a consistent appearance across all platforms with a modern, well supported feature set.

If in-app purchasing gets your attention, this release brings major improvements, with subscriptions now being enabled, and Amazon and Samsung platforms supported. You can read in detail about the work done here in Panos' blog post.

I hope you enjoy all the exciting new features we're bringing you - we look forward to your feedback!