Upgrading workspaces to a newer Visual DataFlex version: Difference between revisions

Updating the decision tree with how things work now (we're not on a fast update scheme anymore)
(Replaced the slash dot referral (how old is this article?) with something more relevant)
(Updating the decision tree with how things work now (we're not on a fast update scheme anymore))
Line 15: Line 15:
# Bleeding edge, deploy beta software. Never do this unless you have an EXTREMELY good reason to do so. You can put your users in a world of hurt by doing this. Is that one feature really worth it?
# Bleeding edge, deploy beta software. Never do this unless you have an EXTREMELY good reason to do so. You can put your users in a world of hurt by doing this. Is that one feature really worth it?
# Stay up to date all the time... (DAW loves you!) This seems like a very nice goal and is only feasible if you have a product that is in tight control deployment wise. If you have to deploy at a thousand locations then this isn't likely for you.. (you don't want to overload your support desk or do you?)
# Stay up to date all the time... (DAW loves you!) This seems like a very nice goal and is only feasible if you have a product that is in tight control deployment wise. If you have to deploy at a thousand locations then this isn't likely for you.. (you don't want to overload your support desk or do you?)
# Stay one version behind.. This is a more traditional approach where you take the time for the product to evolve and for your development and Q&A teams to find the version specific flaws. This works fine for most products, but is less do-able with Visual Dataflex. Why? DAW does not have the habit of patching older versions -even while they claim to support it- so that's a downside of this approach. Instead they tell you to move over to the newer betterer version (with newer bugs too... DAW are you reading this? Do YOU want us to update more often so YOU can sell more client licenses? Then make this scheme work and port your patches into all ''supported'' versions!)
# Stay one version behind.. This is a more traditional approach where you take the time for the product to evolve and for your development and Q&A teams to find the version specific flaws. This is not a bad choice, but beware of one thing. DAW does not have the habit of patching older versions -even while they claim to support it- so that's a downside of this approach. Instead they tell you to move over to the newer betterer version (with newer bugs too... DAW are you reading this? Do YOU want us to update more often so YOU can sell more client licenses? Then make this scheme work and port your patches into all ''supported'' versions!)
# Switch on over when a good stable major version is released with enough new in there to make your users happy. So for example switch from VDF 11.1 to VDF 14.0. This means you don't have to wait on your last version per definition.. pretty soon for example you could change this from 11.1 to VDF14.1 if that fancies you more.
# Switch on over when a good stable major version is released with enough new in there to make your users happy. So for example switch from VDF 11.1 to VDF 14.0. This means you don't have to wait on your last version per definition.. pretty soon for example you could change this from 11.1 to VDF14.1 if that fancies you more.


Suppose you already guessed what my favorite is? No? Correct, I'm on that last scheme, but don't let that stop you from following your own path. It works for me, that doesn't mean another upgrade scheme doesn't work for you.
Even if you deploy on an older version, I still recommend to make your code ready to work with the latest DataFlex version. This allows you to test with the latest version while you still deploy on a familiar base. Once you do move over, there will be less changes in your code and it will be easier to manage the upgrades.
 
Note that it is rarely a good idea to get behind too far as then the upgrades become more work and you will get larger changes in your application just for getting up to date.


==== Smooth upgrades ====
==== Smooth upgrades ====