We've released five patches (also known as hotfixes) for RAD Studio 10.3.2. To ensure you know about all of them, and can install correctly, here is a list and some overview information. If we release any others, we'll update this blog post with details.
When we release a patch, we have a download containing the files and a readme with installation instructions. To ensure you know about the patch, we also blog about it. The blogs also sometimes contain extra contextual information - the readme might have installation instructions, but the blog post might explain why those instructions are the way they are, for example, or it might discuss some other aspect of the patch. We always recommend keeping our blog feed in your bookmarks, because entirely aside from patches, we regularly post about other useful or interesting material.
RAD Studio, Delphi and C++Builder 10.3.2 was released on 18th July 2019 (2019-07-18 in ISO 8601 format.) If you have an active update subscription, you can install via the web installer (recommended) or the offline ISO installer. After installing, apply the patches.
In chronological order, the patches for 10.3.2 are:
Two of these patches (#3 and #5) both change the same file, and for those two it is critical you install in the same order they were released, chronologically. However, in general, we recommend that when you install patches:
Finally, we're sometimes asked if patches are included in the next release of Delphi or C++Builder. The answer is Yes. The issues addressed by a patch are always addressed in the next version of RAD Studio. Here, given these are patches for RAD Studio 10.3.2, that means that RAD Studio 10.3.3 will include fixes for all the issues in these patches, plus additional quality work.
We work hard to ensure RAD Studio is useful for you, and that includes timely fixes for any issues that are discovered after release. Make sure you have update subscription, so that you have access to each point release, which includes many new features and quality fixes - 10.3.2, for example, fixed around 400 issues you reported, as well as adding some significant new features. Update Subscription allows you to stay up to date, and is well worth it.
I'm always wondering if I should install the patches or wait for the new release, saving time. It would be good if you could add an indication of when the next release is planned. Roughly.
We generally don't indicate when the next release is coming, because even if we surround it in "not a promise" kind of text, people will (and very reasonably!) make decisions based on that date. And the date can change for all sorts of reasons, especially if we want to take time for stabilisation, a longer beta if something looks a bit more troublesome than we expected, to add more bugfixes, etc. Then, people might have made decisions that they would not have made if they'd known, and that's not something we want to happen. So we announce dates when we're confident and certain.Here, even today a couple of months after 10.3.2 is out, I would recommend you install the hotfixes rather than wait for 10.3.3.
"And the date can change for all sorts of reasons"
But all software can say that; this doesn't prevent most software, especially enterprise-grade software, from providing release dates. If circumstances change, amend the release dates as appropriate. The only reason to avoid dates is if the development process routinely sees major slippage, and that should cause a reexamination of the development process or the realism of the schedule.
Also, Embarcadero has tended to not release dates *at all*. I'll never forget the time Marco had a "preview" of the newest Delphi release scheduled, and Embarcadero went and released a few days before his webinar. He jokingly called it a "postview" after that, but it was disturbing that even the product manager didn't know the release date.
For software as expensive as Delphi/Rad Studio aimed at Enterprises, it makes it a budgeting nightmare to have to shrug one's shoulders and say "I don't know" when departments are trying to budget for expenditures and want a release date.
" a longer beta if something looks a bit more troublesome than we expected, to add more bugfixes, etc."
When large projects such as PostgreSQL or Python (12 month and 18 month release cycles, respectively) encounter those types of issues they add an extra beta or release candidate release to their release schedule when it appears necessary. These extra releases generally extend the release cycle by a week, not months, and both routinely tend to slip by only 1-2 weeks from schedules planned 12-18 months in advance.
Joseph, you seem to assume many things that I did not state.
We don't announce release dates ahead of time. We do value the flexibility which that gives us.