Posted by: robin in MyBlog on Feb 08, 2010
We received some nice feedback on our care and feeding of InfiniDB blog entry, and we appreciate all of you who were kind enough to respond. We did fail, however, to communicate a few other intentions we have regarding how we plan to release and label the InfiniDB software so here’s some more thoughts from us on this important matter:
For new releases, we plan to follow the traditional alpha, beta, RC framework. Alpha means an upcoming release is not yet feature complete and more features are coming; beta means an upcoming release is now feature complete and we are now only in bug-fix mode; and RC means we think we’ve got the quality right for the new release but may still have to iron out a few last wrinkles. Of course, a new release is developed in a separate and different branch of our codeline than the maintenance done on our most current FINAL version. Anything fixed in our most current FINAL version will naturally be included in the upcoming release as well.
With respect to how we will number our releases, we plan on using the standard MAJOR.MINOR.PATCH numbering scheme. How the numbers are incremented are as follows:
For a PATCH release, these are just incremented normally as new bug fix builds are produced and released to the community. Again, our goal is to have monthly builds for the community for our most current FINAL version and quarterly service packs for the commercial version.
A new release will contain a MINOR number increase when one of two things (or both) are true: (1) when enhancements are made to already existing functionality that shows marked improvement in how the existing feature functions or performs; (2) new features are added that are not large scale in nature, but enhance the overall product’s capabilities. So, for example, in our next release, we will deliver high-speed subquery support for InfiniDB. You can use subqueries today in InfiniDB by setting our vtable mode to pass everything to MySQL, but trust me: you don’t really want to send subqueries against TB’s of data and billions of rows directly to MySQL for processing unless you plan on waiting a while for your response. Because we technically do have subqueries now, the addition of high-speed subqueries would qualify for a MINOR number bump. Also – whether it’s a single number bump (e.g. 1.0 to 1.1) or multi-number bump (e.g. 1.0 to 1.5) - will depend on the number of additions added to the new release and their sophistication level.
A new release will contain a MAJOR number increase when one or more large-scale new features and functionality that do not currently exist are added to the product. These new features allow brand new things to be accomplished with the server that currently weren’t possible or required major workarounds. Of course, a new MAJOR number release will likely contain enhancements to existing functionality and small new features. The vast majority of the time, a MAJOR number bump will be sequential (e.g. 1.0 to 2.0) but it is possible to go more than one level between releases – such a thing is rare but does happen (e.g. Sybase went from version 12 to version 15). As an example, today we formally support a shared-disk configuration for our MPP commercial version. While you can do a shared-nothing setup, we don’t recommend it for production nor support it as the server currently does not have built-in redundancy and failover between shared-nothing nodes today. When we do formally deliver shared-nothing with the appropriate feature set, this could qualify for a multi-MAJOR version bump (e.g. 1.5 to 3.0). We certainly don’t want to artificially inflate MAJOR version numbers so, again, this type of multi-number bump will be rare and most times simple one digit sequential increases will be done.
So that’s our current thinking, but we’re certainly open to your thoughts and will eagerly accept better ways of doing things, so let us know what you think. And thanks again for your support of InfiniDB.