Yesterday in the CodeRage II public chat for the vendor reception there were some comments about upgrading from Delphi 6 to Delphi 2007 by Cass McNutt. I think these comments are great because we need to make sure Delphi is as easy as possible to upgrade. I love constructive feedback like this.
First you have to understand how I use Delphi on a daily basis is completely different than how you use it. We develop Delphi in Delphi. Our version control system contains nearly every line of code that goes into the product. So for me upgrading between versions isn't as much of an issue. Plus there is an entire team of Delphi developers to help out. So I'm trying to put myself in your shoes here.
The main piece of the puzzle you depend on is the IDE, compiler, RTL and VCL. If these change you need to change your code. That's why backwards compatibility of the compiler, RTL and VCL are so important. If something breaks your code you may choose to stick with the current version.
My perception is that 3rd party components and IDE plugins are your biggest concern. If a 3rd party component doesn't support the latest version and the source isn't available you might choose to continue using the current version. This is the same problem when upgrading any complex system such as an OS. This is the same reason I'm not upgrading my Mac at home to Leopard.
My understanding is that there are a lot of developers still on Delphi 7 or earlier. There are many reasons such as the help, IDE performance, IDE requiring .NET, component palette changes, installer, and SDI IDE.
A smaller but equally important upgrading issue seems to be user preferences such editor colors. I think the installer should be able to detect a previous install and migrate appropriate settings to the new install if desired.
So am I missing any other concerns or pitfalls about upgrading Delphi?
Update: I find it interesting and worthy of a note that today in borland.public.delphi.non-technical there is a post titled "Upgrading a program from Delphi 6 to 2007 - What's nessicary". Obviously this is a common problem.
Update: I changed some of the wording above. It was pointed out that I was insinuating that you shouldn't upgrade Delphi. This is not the case and if anyone reads this into my comment above you are reading a sentence out of context. I am simply trying to put myself in the Delphi customer's shoes. So, some rewording has been done to be more neutral.
Friday, November 30, 2007
Upgrading Delphi
23 comments:
I agree with your statements - especially those that deal with 3rd party components without source that you can't use with the newer versions. I personally had this big problem with my software security component.. had to bite the bullet and use another component and recode the security module to use the new one.
Would be nice for components/dcu files to somehow be "binary" compatible across different versions - then you won't have people stuck on "older" versions because of some components.
There are three main reasons for upgrading:
1. The old version is seriously broken in some way (certainly not the case with Delphi 7);
2. The new version contains features that a client wants that do not exist in the old version (e.g. a client is moving to Vista and wants certain Vista-specific features that only the latest Delphi supports);
3. The new version will so markedly improve productivity that you just have to have it (by no means proven as yet).
If none of those criteria are met it comes down to a question of how much the upgrade is going to cost, both in money and in time and effort to migrate. The answers to the latter are often very hard to find, and bitter experience suggests that migration costs are often much higher than the software supplier's rosy predictions suggest.
"Would be nice for components/dcu files to somehow be "binary" compatible across different versions - then you won't have people stuck on "older" versions because of some components."
I agree with Geraldsa.
The component should be binary compatible across versions and this should be given highest priority in the next release of Delphi.
Chris - Thanks for the time chatting on Thursday, and for this post + link. It's an important conversation to be having, IMO.
Anyway, JIC you don't get much notice via trackbacks, I thought I'd leave a comment here letting you know I posted a response/elaboration on this, at my blog, here.
The SDI IDE is the killer for me. Yes, the upgrade cost to my extensive 3rd-party libs (which allow me to fake being a good programmer) are belt-tightening, but it's the IDE that just gives me excuse year after year to wait until Codegear lets me have the choice of IDE's again. I almost jumped at 2005 but heard horror stories about MDI use. Then, the choice went away. And as much as I like a LOT of 2007, the inability to have multiple forms on the screen to copy to and fro from and to look at while working in the code window ... well it just gives me easy access to my inner procrastinator.
Have to admit though that Blackfish looks very, very, very yummy.
Migrating from Delphi 7 (or earlier) to Delphi 2007 is obviously somewhat painfull, although not as hard as you think (I recently migrated a project from Delphi 4 to Delphi 2007). However, migrating from Delphi 2006 to Delphi 2007 should be easy (especially considered this is supposed to be a "non-breaking" release), but my IntraWeb Delphi 2006 project was NOT. For some reason, published properties (such as CSSStyle) are gone or renamed or moved to another base class. CodeGear should had kept a more closer eye on this. When you're using IntraWeb, so much for a "non-breaking" release, I guess (and please, don't tell me this is a separate product from a separate company, because to joe-the-average-user, this IntraWeb thing is part of the product, as much as the rest of the VCL).
Wait a minute. I downloaded the Delphi 2007 beta, and I could swear there was an option for an SDI IDE.
Hi Chris
Your post is spot on. I stayed with D5 for the longest time, because i didn't want the stress of upgrading all my third party components.
I think a lot of people would upgrade to D2007 just for the productivity enhancements (refactoring, improved IDE, etc), but this fear about needing to upgrade and test all their third party components is a road block.
Sooooo include source code for D2007, D2005, D5, D6 and D7. IOW, allow D2007 to compile native native D7 code, for instance.
All the cool new features, none of the upgrade pain.
(I know, i know, it is not as easy as that. A lot of the IDE enhancements require changes to the language... I'm just shooting from the hip, because this is an anonymous post Bwuh ha ha ;-)
Binary compatability of components/DCU's is a HUGE no-no.
If you need version independent components, use a component framework that provides it - i.e. ActiveX.
If you have to use VCL components only EVER use components (in serious work) for which you have the source so that you can recompile them in later (or earlier) versions of Delphi as and when needed.
As for migrating/preserving environment settings when upgrading theIDE...
DO YA THINK!?!?!?!?! Sheesh.
LOL
But seriously, the key stumbling block to upgrading (for me) was quite simply cost/benefit. The $ cost of upgrading from D7 to D2007 simply is not worth it.
Setting aside all of the things that are wrong with D2007 (slow, unreliable, unsteady, clumsy in use compared to D7 etc etc) the "additionas and enhancements" to the language/product are either too little too late (already satisfied by 3rd party solutions, often free, often BETTER than the "in the box" variant, e.g. FastMM) or wholly irrelevant or reliant on spurious differentiating in order to be classifed as "new". "Object types are dead, long live Records with Methods".
But I guess pointing out all the things that are quite clearly and obviously wrong isn't "constructive" enough unless it comes from the right people, eh?
:)
Cass,
I don't think your blog is indexed by http://blogsearch.google.com/.
I am not sure I get all the /reasons/ for not upgrading: I jumped ship from D6 to D2007.
- Not DCU compatible: Who on earth should decide to buy comps w/o source ??? Forget upgrading, just consider your supplier wins the lottery and goes awol, what would YOU do then ? without Codegear's help you'd be going down the drain anyway
- Not an MDI editor ? Open 2 instances of Delphi when you need it. I routinely run with 2 or 3 instances of Delphi on a 800MB ram virtual machine.
- slow, crash prone, .net dependencies ... we are in 2007 guys, use virtual machines and setup ONLY what you need on each machines. It is a well-known practice in the Windows world to dedicate one server to one task, do the same for your dev machines. Life's so much easier then.
- productivity enhancements: name new debugger, (some of the) refactoring, code completion, class completion,
component palette (type first few letter and off you go, I used to hate it, now it is OK if not better). I find myself loathing having to go back to D6 (which I keep for the help but will soon kill at the rate Codegear is moving, and on a separate VM)
- we are in an ever evolving industry I am surprised how many developer resist change. It is bad enough to have users resisting ... :)
- Cost of upgrading: Buy SA and you set yourself a budget aside every year. If you were in the building trade, you would have a budget to buy new hammers, screwdrivers etc... which year on year would do exactly the same (you do not have 1000 ways to improve a hammer anyway) and you would think it is normal. Here you have a budget and the replacement tool does more than the previous one.
Nice post, Chris, thank you!
Yes, speaking about upgrade, the main point is 3rd party components, as the others
said. Burned several times, we follow the main stream path, having the source of all of our components. Trying to be constructive, I'll spot several hurdles in the upgrade race from this POV. We (and many others AFAIS from newsgroups, blogs etc.) have many more components than Project Manager + Package Installer/Manager is designed to handle in a streamlined upgrade workflow (imho).
For this, perhaps it's better to:
1. QC#55544 - Split the conditional defines between Bpl interfaces / Compiler version / Language version in order to not be forced to update the .inc files manually and recompile the packages one by one.
2. QC#55546 - To improve the package installer allowing batch installing of packages. based on what's installed in the current version and/or on a TMemo content/.txt file with .dpk paths. (For breaking releases this needs the point 1. to be fixed)
- Not needing some feature really hard to act as motivation. Inline comes closest. New language features are mostly a joke.
- Not having to upgrade because nearly the entire component market still supports at least D7.
- (no need for .NET, we moved to VS2005 for ASP.NET 2.0 1 1/2 years ago)
- We are machine builders, and sometimes to debug the machine's PC when we are really stuck we install D onto the machine. D7 is quickly installed onto modern machines.
- Help would be an issue for me, (I like the D7 one, at least after you remove CLX topics) but only one that I heard in NGs. The other ones kept me from upgrading.
Note that we do own D2006pro, it just didn't justify to invest the time to upgrade. Maybe soon it will happen due to a requirement for 16 byte alignment support
I did upgrade to d2007.win32 (trial this time), i converted all our 3th party stuff and off we went. (we alway's buy 3th party sources just in case, so no problems there)
But we stranded on the large file problem within 1 week. This is actually the third time in row in the BDS range the product is jumping on us, 2005 crashed right out of the box (updates were even more buggies), 2006 wasn't that much better (well, if you're patient and with all the latest updates) and 2007 is without update#4 even more shit.
I don't fancy all those new things, in the first place i want something that can actually compile my old code without any crashes. So sorry dudes, do a better job for 2008 please.
Fpc is already pretty good and lazarus needs some more work but i think that will be the delphi.win32 killer within 2 years.
The mandatory activation rules for post D7 versions, the absence of any compensating escrow arrangements, and the complete lack of interest by CodeGear management in the very survival of their clients makes all and any advantage of new versions totally superfluous. The only people who can responsibly upgrade to this arrangements are those with relatively trivial applications which could be rewritten as required, or have the capability in some way (including pirate backups) of overcoming the long-term unavailability of the activation servers (or a change in rules which otherwise disallowed reactivation). Of course the terminally unaware, incurably optimistic, and those with a death wish (or a risk fascination approaching that level) will also have upgraded. Other serious situations such as the abysmal download arrangements, screwed help system, and utter inability to avoid the .net overhead even optionally are shadow considerations in comparison. But even those factors on their own swamp the advantages outside .net of the newer versions. Your CEO is letting you down. I am quite sure you and your technical colleagues are doing sterling work, and I would love to be in a position to try some of it out.
m. Th.,
You can open up a project group, select all projects, right click and install all packages.
Here are my reasons for not upgrading:
- IDE bloat
- Activation
- Lengthy install procedure
- no compelling new language features
- better help in old versions
- Windows only
- using .NET is cheaper and easier
- .NET runs on more devices
- many .NET jobs out there
What would make me upgrade?
- a decent installer
- new language features: native generics, unicode, collections, better support for parallel programming
- a leaner IDE
I don't mind if the IDE uses the .NET 2.0 runtime. But I don't want to install all those SDKs and prerequisites. And I want to download the software, hit install.exe, wait for 2 minutes and start programming.
Back in 1999 I chose Delphi over C# 1.0 for mostly two reasons. The lean IDE, the incredible fast compile speed, the great help, and the ability to write native crossplatform applications (Kylix).
Kylix is gone, the snappy IDE is gone, the help is gone and the compiler is not that much faster than the C# compiler anymore....
Of course, if you don't use third party you'll be safe. Just use BDE and Quickreports and you'll have no problem updating.
Yes, they provided an alternative to BDE. Pity that dbExpress was totally unusable for years, and still doesn't have the versatility of BDE -not that I want to use BDE anymore, but that's what keeps 80% of my time in Delphi7-
If they had provided a better dbExpress and some tool to help converting from BDE that would have made a difference. At least the cost of converting would be low enough to justify it.
I *nearly* upgraded from D7 to Delphi 2006 but gave up when faced with .NET personalities.
I did upgrade from D7 to D2007 (win32) because:
1) Form design with run-theme makes UI design easier,
2) A few of the language enhancements looked interesting,
3) I was hoping for VCL updates (sigh!)
4) I prefer to upgrade in small steps.
5) I want to stay on track for the VCL with unicode support.
6) Fastcode included!
Overall the upgrade process was fairly painless (I don't buy many components and then only with source) and it gave me a chance to sort out (again!) my own components.
The downsides of upgrading I found:
1) .NET with all the SDK overhead
2) Broken help (much better after update 3 but still full of irrelvant stuff)
3) Sluggish editor response
4) ****ing browser infestation. That welcome page can go and is that a browser control being used for the hint window?
5) SDI form/code editor. It's much less efficient and the Object Inspector is no longer as useful.
Chris -
- Yeah, my blog's indexed there. Google was just slow that day I guess. : ) ('course, I doubt my blog is exactly at the top of Google's indexing priority list)
- Good call on the re-word. I found myself kind of wondering that as well, but assumed you meant what you're more clearly saying now.
- Man, this community is passionate, isn't it? (Maybe the word is vociferous...[grin]). The purely-negative comments are always such a drag (reminds me of Ken Moss's "No Birds" post a couple years ago (can't find the original, but a ref to it is here )). Hopefully you guys have asbestos coats you can wear when needed. ; )
- Does the batch package install thing you're talking about help someone w/my problem(s) at all?
I'll probably post a little more on this, hopefully some useful thoughts, tomorrow sometime on my blog. (Assuming I find the time).
Me again...
Thanks again Chris for responding, but can we make a small calculation? :-)
We have
* a part of DevExpress components (not their full VCL offer but a great part of it): 72 packages.
* Jedi VCL: 63 packages (they provide also some project groups but you cannot click on the project group to do an install...)
* Jedi VCL needs JCL: yet another 10 packages
* IBObjects (well known & spread data access library for Firebird/Interbase): 20 packages
* FastReport 4 (well known & spread reporting library): 30 packages (these aren't all, 30 is what we have installed)
Total: 72+63+10+20+30 = 195 packages
...and this not to mention other smaller libraries & in-house components which we have. Also, not to mention that we have some legacy libraries and we are in process of migration from them. As you see (dunno if you know what the community use most) I included in my list only the most used libraries, just to be a 'common case'.
And also, not to mention that exists dependencies between these packages inside of libraries ('Express Editors' must be installed before 'Express Quantum Grid' aso.). Fortunately some of these libraries provide installers to help you automate the task but when you must upgrade to a newer version of Delphi...
1. You have to keep in mind all the libraries (read: package groups) which need to be installed. (Usually, we hack the registry for this)
2. Many of these installers have some drawbacks like:
- unwanted packages -> IDE slowness, component palette bloat
- problems with different directories (dcu output, search path etc.), and other options which these installers doesn't provide (eg. injecting stack trace info (eg. 'JCL debug info') in the compiled packages aso.
- sometimes we make a change (eg. fix a small bug) in their sources and we want, of course, our version if the fix was slipped out.
3. Some component vendors (not listed above) are out of business/doesn't provide a version for the latest Delphi and we need to maintain ourselves the packages. (The installer doesn't recognize the newer Delphi version, of course).
And, yes, we finally do right-click-install (sensibly more than) 195 times.
These are our motives for asking to do the upgrade a more streamlined process. But it seems that's a common issue in the community. OTOH, the main reason for upgrade is *if* the Tiburon will fulfill the wishes of CG's user base. That's why, imho, you (R&D team) should be a little more communicative because "we do use Delphi in a very different way that you do" :-). Your blog is a good start, also Allen did something in this direction, but isn't enough imho. Thanks again for your post.
...rereading my post I saw that I wasn't clear in a point: yes, we know the multi-select feature in the project manager, and (of course) we use it, but giving the great number of packages... (Sorry for double posting)
m. Th.,
Thanks for the list of 3rd parties. I'll talk with QA and see what we can do to test them. That is a lot of right clicking. It should be easier.
The Delphi community totally rocks and it's always good to give back and keep you guys in the loop as much as I can. And with this blog we can have some good two-way communication. It's good for everyone.
Post a Comment