Ian Barker

Thanks for letting us know about this. I have raised it with the PM team to look at and validate ASAP. FWIW my own personal mobile is a Samsung device.

You need to use a <PRE> tag and then set the background. This article tells you how: https://stackoverflow.com/questions/10349883/can-i-add-a-background-to-a-pre-on-blogger There are better ways of doing it - I suggest you read this post: https://blog.paoloamoroso.com/2021/10/how-to-add-code-syntax-highlighting-to.html

A constant you can assign at run time? Is that a one-off thing - assign once and then it's immutable? If not, then it's a variable, not a constant or have I misunderstood?

Well, by that I assume you mean you're getting marketing emails. Yes, they are on a different system. So are the blogs and a few other servers and services - for example QP and my.embarcadero.com download servers are working. For the email you don't want there is always an unsubscribe link - if you click on that they will remove you from the ones you don't want - in fact it's a legal requirement in most countries that they do.

There have been people speculating in various forums but it's not ransomware.

Servers... plural. That's the problem. If it was a single server that had gone bang, I think it would have been considerably easier. I don't know the full details, but it was a cascade of events and multiple affected servers and hardware.

It is dead hardware. Not ransomware. I think, in many countries it is a requirement to report a Ransomware attack (in the US I think it might be the FBI or Homeland Security - I'm not sure). It's definitely a hardware outage.

I think it could have been better worded - it's not that there are different levels of beta testers as such. It's more that the betas are released to a progressively wider audience. Early betas are generally released to a hand-picked cadre of users who either have a very specific situation which has a significant bearing on elements of the beta or are long-term 'advanced' users such as MVPs along with key tech partners. As the betas become more stable that audience is widened to more people who can receive value from a beta which while useful might still have potential instabilities which some could find challenging. This iterates with a wider and widening group until we begin to roll out to a broader general audience such as key accounts and known large projects, culminating in a general beta which goes out to people who have a maintenance subscription. There are different types of forums where the level of engagement is tempered to suit the type of beta customer. For example, MVPs often discuss things of a very esoteric technical nature with a more profoundly explicit type of conversation which, while entirely professional, might be more akin to a collection of colleagues and friends discussing a SNAFU in a particularly blunt way. These kinds of conversations don't sit so well among conversations with, perhaps, a 'regular' customer who is merely trying to see if the new beta solves an issue they have had with their project. I want to emphasize that this is not to bring about a kind of elitism and I try *really* hard for Embarcadero to be approachable by anyone - and I do get emails from all sorts of people, so I think that message is starting to be understood. I am here, I am listening. We are listening. The differentiation is more to ensure the level of interaction is appropriate for the expectations of the persons participating. MVPs are chosen for a multitude of reasons. Tech Partners are also the same - and some MVPs work for Tech Partners, but many Tech Partners do not have that kind of relationship with us. The same is true of customers who are neither MVPs or TPs and are trying out the beta thanks to their maintenance subscription. Administering the betas such as managing the beta keys and validating the requests to join the beta can be an intensely onerous experience which can place demands on internal staff at a time when they are already working close to capacity preparing for the eventual full release. Because of that, and in recognition that a valid premium or maintenance subscription should bring additional benefits such as access to betas, our current preference is not to simply push out a beta to one and all. We are also constrained by legalities such as getting sign-off on sub-licensed materials, EULAs, ensuring any OSS is properly credited and made available. That's not even an exhaustive list of what has to be done. We obviously want to ensure that as many people as practical can participate in the beta because the more that try it the more likely we are to shake out bugs or other issues before we release to GA - but we also do not have unlimited resources and we simply cannot currently let everyone on the planet join the beta. I know not everyone agrees. We are trying to listen more and more to your feedback, good or bad - we want to know the whole truth - because that's the best way to give you what you want and to make RAD Studio a product you love, and which genuinely adds value to your work. I promise you that everyone I work with is remarkably passionate about creating and sustaining a quality product that you will keep on choosing to create applications that help you achieve your goals and successes too. Ian.

This is specifically allowed as long as it doesn't directly expose any NDA Beta features.

Whilst @dummzeuch makes a good point about us (Embarcadero) wanting to keep a track on NDA breaches I can also see a flipside too which is more in line with what Tommi says. I've made a note to see if we can do something about providing information about compiler conditionals for future betas. Note that for those on the Beta we did allow component vendors and OSS projects to refer to things like "added compatibility for RAD Studio 12" in their release notes and commits as long as they did not refer to or expose any functionality which was specific to version 12. We want to balance the requirement for confidentiality (which is required for sometimes non-obvious legal or technical reasons) against trying to work with repos and Tech Partners to make life as easy as possible and to achieve compatibility as smoothly as we can. All MVPs and Tech Partners are regularly briefed and have several ways to get hold of me directly to ensure communications in both directions are as smooth as possible. For all our users, however, I am here to help be a bridge between Embarcadero's internal teams and all of you - it is quite literally my job. The best way to contact me is by email - ian.barker@embarcadero.com - and I will reply. I don't have all the answers but if I can't help directly, I will speak to colleagues and get the information from the people who do know it. We are listening. I am listening. I work with some truly remarkable, technologically passionate, talented people and we all want the product to be the best it can be, for you to get real value from using it, and for it to improve on an upward curve. That's not some kind of marketing hot air - it's a fact. In cases like this, the version number conditionals and so on being made available earlier, I thought we did this already but if that's not the case then let's see what we can do to improve on that in the future. Ian Barker. Embarcadero Developer Advocate.