Based on the recent EMBT survey and comments here by Marco Cantù, it seems clear that new versions of Delphi will focus on new features.
Based on the recent EMBT survey and comments here by Marco Cantù, it seems clear that new versions of Delphi will focus on new features.
We've been told before that nobody, or not enough people, will pay for just bug fixes and improvements, but I don't believe that is the case. Who would be happy to pay for an upgrade that was primarily focused on bug fixes and performance improvements? I know that I would.
We've been told before that nobody, or not enough people, will pay for just bug fixes and improvements, but I don't believe that is the case. Who would be happy to pay for an upgrade that was primarily focused on bug fixes and performance improvements? I know that I would.
Well, there were a survey questions about current quality of the various areas of the product, so people can provide specific feedback. While the survey is important, there are business decisions beside it. Quality increase is a big feature we plan focusing more on (already doing that, of course, but more difficult when you also want to cover new platforms)
ReplyDeleteThe problem I see with this is, essentially, how many people think they should pay for a new version including fixes that should have been addressed a long time ago. This is what I think is the problem.
ReplyDeleteMind, I would also probably pay for a bug-fix only version(IF it contained hundreds of bug fixes, and I mean in the order of at least 1 thousand or just shy of it).
It's a difficult balance to strike...
Regards,
A
Andrea Raimondi I think that a version that was only, or mainly, fixes and improvements / optimizations should have a lower upgrade price than a standard upgrade. This is what Apple did when they released Snow Leopard as a fixes and improvements to Leopard.
ReplyDeleteIf you are on an SA, every upgrade is lower priced.
ReplyDeleteBut - yeah - EMBT really needs to put their back into some serious baseline solidifying.
XE4 is riddled with old bugs that should have been long gone.
Uh, I though that being on SA meant that you didn't pay for upgrades (at the same SKU level). Oh wait, they ditched that idea with XE4.
ReplyDeleteEven though you don't pay the upgrades, you pay the SA.
ReplyDeleteDid they really ditch that idea with XE4?
You must be joking, surely?
A
Marco Cantù If the user base is as large as claimed you should take advantage of those users by accepting patches to the RTL/VCL/FMX from them.
ReplyDeleteAdd change detection to the IDE to monitor the source. Prompt the user to submit a description of what they fixed and a diff of the source using their edn account. Toss in an IP reassignment agreement to appease the lawyers. (some recognition in the about box wouldn't hurt either)
On your end you'd just need someone to approve/reject the patch and decide when to roll it out to the rest of the users.
Andrea Raimondi Nope, even if you were an SA customer, you had to pay for XE4. I think it was around $49.00, but still.... WTH?
ReplyDeleteAh right! To be fair, though, that was the second release in the year and I am not quite sure what the terms for SA are...
ReplyDeleteLars Fosdal And there's the rub. Upgrading to new features I don't need, and the persistence of bugs which have gone unrepaired for years (in some cases) just doesn't make a business case for me to commit my money.
ReplyDeleteKenneth Cochran We are considering such an idea, but it is not trivial. The largest effort is not to patch the code and write the fix, but make sure the fix doesn't brake anything else in our and (potentially) our customers code base. That's not an easy task.
ReplyDeleteAndrea Raimondi We fix hundreds of bugs in an update. And XE4 fixes a lot of issues in XE2 and XE3, beside the new features. We need to do more, but it is not we are doing anything. The IDE stability, for example, saw real improvements recently. Proven by customers, that decided to upgrade exclusively based on fixes they had asked for and not for new features.
Marco Cantù Sounds like a good candidate for Nick Hodges idea to open source the unit tests. As the tests are improved and expanded you'll eventually wind up with a executable specification for the entire code base. New tests could be submitted using the same process as patches.
ReplyDeleteOf course this assumes:
1. Developers write good tests
2. Developers will run these tests before submitting a patch.
I'll concede that this may be assuming too much and it doesn't take into consideration customer code that depends on the presence of certain bugs to run properly. At which point the "bug" has become a "common law feature".
Code that's dependent on a VCL bug needs fixed when the bug does. It should be considered part of the cost of upgrading, along with other things that need done.
ReplyDeleteEmbarcadero has already decided that it's okay to make other massively breaking changes like Unicode, reorganizing the VCL, DisposeOf, and they're tinkering with zero based strings. But maintaining bugs to "not break code"? I call shenanigans.
New features? Yes. New for at least 2 versions unusable features? No!
ReplyDeleteMarco Cantù I guess you know the numerous posts in the community about the poor source quality and the obvious lack of knowledge amongst the devs that coded particular things. That needs to be addressed if you want to ship new features that are of quality instead of just being a line on the what's new list.
Simon Stuart Some features can't be made by anyone except the compiler vendor. And exactly that is their job imo.
ReplyDeleteI wish Embarcadero finally relesed a "LTS" version of Delphi (like Ubuntu) and provided support for it (without adding any new features, just fixing bugs) for 3-5 years instead of the current situation where maintnance for any version lasts for just about a year. New features, if anybody needs them, would go to new versions.
ReplyDelete