VistaDB 3.2 We are going to skip the release of 3.1…  Not really, we are just skipping the name. The current naming has always been confusing and a number of people have complained about it in the past. 3.20.1.BUILD is the current DLL versioning. Engine 3 Runtime 2.0 Release 1 Build x Confusing because it is called 3.0, not 3.1, and the DLL already has the 20 in the DLL name as well. We are going to correct it in the next release, 3.2. It will now be versioned like this: 3.2.BUILD.rev Engine 3 Release 2 Build x Rev is for internal revisioning. The DLL will still have the 20 in the naming so you know what runtime it was built to run under.  The 3.x framework (since 3.0 and 3.5 are the same runtime as far as we are concerned) will be just named with a 3.  So we will end up with VistaDB.NET20.dll and VistaDB.Net3.dll in the next release package. What, no 1.1 provider? We are going to drop the 1.1 provider in the 3.2 release.  From our polls and discussions with users there are only a handful of users using the 1.1 provider.  It is another thing for us to maintain, and it is holding us back.  We really want to include new features that are only available in Dot Net 2, but have held off as long as we could.  If you need 1.1 support I highly recommend you purchase the Source Edition license.  It currently includes the 1.1 provider, and you can then use it and update it as needed for your own needs. Lost lock files are the largest item.  Right now we cannot detect when a process has died and left lock files on the drive.  Your only fix is to pack the database.  This is not the best solution, in fact Dot Net 2 provides a really nice way for us to specific that if the originating process dies, the framework should cleanup those lock files.  This will allow us to handle the lost locks in a much more efficient manner. What about Mono? I have done quite a bit of testing under Mono 1.2.4 and the 2.0 provider works.  There are still a few API calls that are not implemented, and some things like isolated storage don’t work.  But that doesn’t work in the current 1.1 provider for Mono either.  So we are continuing to work with the Mono project to support their efforts.  VistaDB 3.3 will be classified BETA We will classify VistaDB 3.3 as BETA due to the number of large new features and changes. TSQL Stored Procs are going to be a work in progress for a while as well.  So we will declare the 3.3 tree as a beta tree, and continue to release stable builds for 3.2 in the interim.  This means only subscribers will have access to the 3.3 tree until we promote it to stable. We will begin to roll out test versions of TSQL proc support for subscribers to get feedback as quickly as possible.  Feature Requests  Do you have a wish list for features you would like to see supported?  Please submit them in FogBugz as feature requests.  You may also post them in the forums (look for the 3.3 feature request topic).  We have collected a few dozen TSQL procs from companies, but we are going to need many more examples of how you use TSQL Stored Procs.