I get questions all the time from users who are confused about our release cycle and product versioning. I think I may finally have come up with a good analogy thanks to some conversations with users.
Single Version?
The Single Version moniker on the VistaDB Personal and Lite editions can be confusing. These are both single releases of the platform. You get all the builds within that major.minor, but when a new release of the platform comes out they are not included. The “dot release” is not simply a rollup of the previous builds with a new name. They are a new feature set and release point for functionality.
Maybe they should be called a single release edition since a release to us is a major.minor. But I think that term would be even more confusing to most users.
A Release is a promise of functions and features
Our goal is to ensure all major.minor builds are compatible with each other in both API, and functionality. We strive very, very hard to never break an API until the next bump in the version. Otherwise you could end up with two builds of the same major.minor that behave differently, or are not runtime compatible.
Each time we need to change an API we bump the product minor to ensure that everyone knows they are going to need to compile their app, not just replace the DLL. Normally for builds within a single release you can just drop in the new DLL and continue to run (with whatever fixes, updates were included of course).
Apple OS X as a platform
Apple OS X (10) is really a platform. You know when something says OS 10 compatible that you have a certain set of minimum features that are different from OS 9. But OS 10.1, 10.2, 10.3 are all really new releases. Not just rollups of service packs or bug fixes.
Each “minor” release is a paid upgrade from Apple specifically because they are really new feature sets and additions. And not all software made for 10.3 will run on 10.0 if they take advantage of those new features.
VistaDB 3 platform history
VistaDB 3 is a platform for our 100% managed code database engine. It is very, very different under the hood from VistaDB 2. They really could have been called two different product names. Even though they are built upon the same base foundation of philosophies and design principles, they serve very different needs.
3.0 was the initial release of the platform and introduced the new base level features for the platform. But we always intended to add new features to the platform over time (and we did add a lot).
3.1 was skipped for technical reasons, and 3.2 was the next release. It included a lot of roll ups from previous to be sure, but it also introduced several new features and API changes. The number of API changes was the primary reason for bumping the release numbers. Once again, just to ensure everyone knew their were API changes that their code would have to be tested against.
3.3 introduced major new features like T-SQL Procs so it was another new release point.
VistaDB 4 platform
VistaDB 4 is our latest platform that includes Entity Framework support, and continues to build on our SQL Server compatibilities while adding new features to the engine and tools.
We had considered naming it VistaDB Cuatro (spanish for 4) to give it more of a product platform image. But we figured no one would be able to spell it correctly, and their used to be the Quatro database product (could be a little misleading). Then we would have had a 1.0 release, 2.0, etc. Each of them would stay within the VDB4 product platform, while adding new features.
Instead we decided to stick with the 4.0, 4.1, etc naming convention. I am still not 100% convinced one way or the other is better, just different.
VistaDB 4.1 is under way
We are hard at work on VistaDB 4.1 already. Not ready to unveil the feature list quite yet, but we are continuing to add both major and minor features and API changes to the engine and product tools. This is a “major” release in that the entire engine is basically revved for the new release.
What are Service Packs?
Users often tell us that Microsoft names things like .Net 3.5 to mean the platform and then SPs are the post release changes. We call those builds. So VistaDB 4.0 is the initial release of the 4.0 platform, but there are builds 2-10 right now. Any app written against Build 2 should also work with Build 10. There are no API changes.
Microsoft tends to have a much longer rollup and hotfix cycle than a small company like us. That is one of the benefits of using VistaDB, patches and updates are available every month. The last fix we got from Microsoft to the .Net framework took 9 months from the time they told us it would release just due to the extreme long cycles between their releases.
Same thing, only different?
It is not that one way or the other is better, they are different. This release early and release often mentality is something I have always embraced in all my products. It is a key reason for users to have subscriptions. You get all the updates, builds, releases during the subscription period. That ensures you have a healthy platform, and helps ensure we have the revenue stream to provide that platform.
Many companies go through a release cycle, and then the product stays dormant as the development team moves on to other products for a cycle through it (Microsoft does this with some dev teams as well). This means you have a stagnant platform during that cycle period until the developers “come back” to the project. I don’t want to do that.
We could split people and spend more time on other products, then cycle back around to the core again at a later time. It would probably be more profitable for us to do so, but I think we have tons of ideas for things to do within the engine and tools. To split us off would be counter productive in my opinion. I would rather add new product lines once we can afford to hire full time resources for them, rather than time slice what we have today.
This “full time” aspect of the team on the engine does add to it’s engineering costs significantly, but I feel with a good subscriber base who appreciates the release cycles and their goals it should be sustainable. That is where subscribers come in for us, they help regulate that cash flow so we don’t have to do a release cycle and charge for upgrades to pay for it, then rinse and repeat. This is a cycle I see too many small companies fall into.
Version 14?
Heck, look at Winzip. Is there really a need for it to be version 14? No, they just need to sell upgrades every year to continue to pay for the staff and resources of maintaining the product. I never understood why they didn’t just offer a low annual subscription that keeps everyone up to date. Instead people buy 1 version, then wait until it can’t run anymore before they finally upgrade to the current release.
Subscribe