VistaDB.Net Logo

VistaDB 4 Editions and License information update

by Jason Short 28 July 2009

We have decided to rename the 3.6 release as VistaDB 4 for a number of reasons I will outline below.  There are enough major and minor features, plus breaking changes that we have decided to bump the major number.

Entity Framework (EF)

We will ship the Entity Framework provider with 4.0!  I got a very large response from the last EF blog post I did about whether to ship an EF rev 1 provider or not.  The vast majority were quite positive, and stated that the EF 1 spec is out there and therefore we should support it even if it is later replaced by Microsoft. 

“It is part of the ADO.NET 3.5 spec, so I think you should support it!” - JB

Some were adamant that we not “pollute” our provider with 3.5 SP1 and force them to upgrade.  I think we came up with a great solution to the problem.

The Entity Framework Provider is a separate assembly for .Net 3.5 SP1 that installs beside the existing .Net 2.0 SP1 provider.  When the EF runtime queries the provider for support we dynamically load the EF assembly only as needed.  It does not require us to maintain two builds of the engine, or to worry about breaking our current assembly.  We still only have to ship a single copy of the engine, but now with an added EF assembly.

Versioning and Binding

VistaDB 3 has always suffered from a problem of binding redirects.  We build assemblies with the AssemblyVersion set to Major.Minor.Release.Build (3.5.1.78 for example).  This type of fully numbered assembly means that you often get an assembly not found exception when you install a new build until you recompile, or you have to use Binding Redirects to tell an older assembly to use a newer build.  This has been quite a problem for third party tools who do not track our builds that often.

We were always told to build a policy file and put it in the GAC to force a redirect for all installed applications to our current version, but I never liked this approach.  What if you want to run multiple versions side by side?  What if one application can’t handle the newer versions changes?

In VistaDB 4 we are not building with AssemblyVersion set to 4.0.0.0 for all builds that are compatible with each other.  The AssemblyFileVersion is now the only thing that tracks the build (4.0.1.x).  This means that any application bound against a 4.0 release will all automatically redirect to the current version installed in the GAC, or to their local directory.  You can still get the full information from the assembly by right clicking it and going to properties (it shows the AssemblyFileVersion).

We will now only change the AssemblyVersion when there is a reason why you would need to recompile.  For example if 4.1 contained a new interface or a change to an existing interface you would need to recompile.  All 4.0 compiled apps would not automatically load the 4.1 assembly until they were rebuilt (and hopefully verified to be correct).

SKU, Pricing Changes?

There are a number of SKU changes that are coming as a result of this restructure, but all existing users will be mapped up to the most favorable SKU for them.  If you decide at your next renewal that you don’t want to be in that bracket, you can always step down to another SKU and only pay the renewal fee for that SKU. 

We want to ensure that users get what they want, how they want it.  Based upon feedback we have gotten over the past few months there are a lot of people who feel quite strongly about our pricing model.  I personally liked it for the simplicity of purchase.  But a number of small business owners felt that we were “forcing” them to buy more than they needed.  I still don’t understand this considering the per seat pricing they wanted would actually cost them considerably more money.

There are other differences other than what is listed below, I will build a product matrix and put it on the site.

VistaDB Lite Edition – Per install single version price

We hear from some users that they only build small internal tools for their company and they don’t want to pay a lot.  “I don’t need support for these little tools” is a common phrase we hear.  We created a new VistaDB Lite Edition SKU specifically for this type of user.  There are no Commercial Licenses available, there are also no Visual Studio tools or EF available at this price, and only a small window of maintenance updates. 

VistaDB Personal Edition – Per seat single version price

The VistaDB Personal Edition is being modified a bit to no longer include a subscription, but it does still include the Visual Studio tools.  The subscription has been removed (and the price dropped as a result), and some of the advanced tools will be removed as well.  What we hear from a number of individual developers is that they only want to buy this one version, they could care less about maintenance or updates – they just need it to be cheap for them.  This edition will only include a small window of maintenance updates, after that period the user much purchase updates.

VistaDB Professional Edition – Per seat annual pricing

]We hear from users that they want their subscription plan to include everything so they don’t have to think about what they have and don’t have included.  This has always been our subscription model – you get everything you need for a fixed price without having to worry.  This plan has been renamed to the VistaDB Professional Edition, but is essentially the same.  If you want a fixed price way to get everything and control your annual development costs through the subscription model this is the best plan available.

VistaDB Corporate Edition – Per site annual pricing

The VistaDB Corporate Edition continues to be for the larger companies that want to use VistaDB on a site wide basis without concern for individual developer costs.  This will now be the only way to get a site license or the VistaDB Source.  Purchasing at this level is no longer required for companies of a certain size.  The company can decide if they want to pay per developer, or purchase a Corporate License.

 

License Changes

Any license change is always going to be a hot button for people.  We have always stated that each user working on a project be licensed for VistaDB, but it does not always happen.  We are now going to start enforcing this by building in a licensex provider that happens in Visual Studio at compile time.  This means every machine that builds an EXE that uses VistaDB (even through an intermediate DAL) must contain a valid license at the time of the compile.

Embedded Assembly License

Companies who ship us as a DLL as a commercial API will need a special type of license to embed in their assembly.  We are currently calling this an Embedded Assembly License.  If you currently build all your executables you do not need an Embedded Assembly License.  If you currently use VistaDB in an API that is assembly based (not an EXE) you will require this new license.  We will not be granting these Embedded Application Licenses to Lite or Personal edition users, and they will be an add on to Professional users. 

Think of it like how Visual Studio Express works – you can only build certain types of projects.  If you need to build Windows Services, for example, you need Professional Edition or higher.

What about existing users?

We of course want to ensure that all existing users are given their current expected level of purchase or higher.  We will not downgrade someone to a lower edition without their explicit request to do so.

Personal and Single Developer Subscribers will be upgraded to the VistaDB Professional Edition with the same number of developer licenses.  This is a direct match for these users.

Personal Editions without a subscription, or Single Version purchases will not be upgraded, only updates for the version they purchased will be available in the Account Manager.

Small Business Edition customers will be upgraded to the matching number of VistaDB Professional Edition licenses.  If at your renewal time, you do not need all the licenses, you may downgrade the number of total licenses to the current number of installed copies.

VistaDB Corporate Edition customers will be converted to the much more inclusive VistaDB 4 Corporate Edition.  The VistaDB 4 Corporate License include the full Engine and EF Source code, a single site license, support tickets, and much more.

If you are an existing user and have questions please open a ticket from the Account Manager (do not post your information here on the blog!).  We will be happy to explain the options to you. 

EDIT: Updated the information to correct the term Commercial License with Embedded Assembly License.  You do not require a special license to ship a commercial product with VistaDB.  The only time you need an Embedded Assembly License is if you ship your product that other developers later compile into a final EXE.  If you build the final executable(s) for your product you do not need this type of license.

 

Comments

28 July 2009 #

Martin

[quote]We are now going to start enforcing this by building in a licensex provider that happens in Visual Studio at compile time[/quote]
I'm a single developer and use one license on my notebook and the other on my desktop machine. My build server running FinalBuilder has not needed any license. Am I right that this change will now require to install a license on the build server? And how many licenses are available?

Martin Germany

28 July 2009 #

Markus Doerig


Special Thanks to you guys, that you have reconsidered your Licence Plans.

If i all understood correctly, the new Plans fit better the needs of us.
And i'm happy to pay for support and updates.



Markus Doerig Switzerland

28 July 2009 #

js_vistadb

Yes, we are listening and trying to incorporate feedback from users.

I don't find very many single developers who have 2 machines and an automated build system as well.  We will be offering build licenses at a discounted price for those situations, but they will not be available on all SKUs (no build license for a Lite edition).

js_vistadb United States

28 July 2009 #

js_vistadb

I also meant to add that the GetSchema changes in the current build to support EF were a lot larger than we originally anticipated.  This was another entry in our bump the major version reasons list.  

js_vistadb United States

Comments are closed

Powered by BlogEngine.NET and VistaDB

Log in