Call for Delphi 12 Support in OpenSource projects.

[Uwe Raabe 1890]

I'm not aware of something like that. There is a change regarding IFEND since XE4:

Quote

Before the XE4 release, $IF statements could only be terminated with $IFEND, and the $IFDEF, $IFNDEF, $IFOPT directives could only be terminated with $ENDIF.

At XE4, this changed so that $ENDIF became an accepted terminator for $IF, $IFDEF, $IFNDEF, and $IFOPT.

 

[Vincent Parrett 657]

11 minutes ago, Uwe Raabe said:

There is a change regarding IFEND since XE4:

Which was is a PITA as it makes inc files just a tad more complicated than they would be otherwise. I usually have something like this so I can have one inc file that supports versions before and after XE4

 

  {$IF CompilerVersion > 24.0 } //XE4 or later
    {$LEGACYIFEND ON}
  {$IFEND}

 

[dummzeuch 1392]

2 hours ago, Anders Melander said:

So, can anyone remember which version of Delphi broke that scheme?

 

It's not broken now, but I'm certain that there was a version after Delphi 6 that somehow broke {$IF} so it couldn't be used if backward and forward compatibility was needed.

The only problem I remember is that early versions required {$ifend} rather than {$endif}. Apart from that checking the compilerversion should work for all versions after Delphi 6 (I cannot speak for Delphi 8 though, I skipped it).

[dummzeuch 1392]

8 hours ago, Vincent Parrett said:

Which was is a PITA as it makes inc files just a tad more complicated than they would be otherwise. I usually have something like this so I can have one inc file that supports versions before and after XE4

  {$IF CompilerVersion > 24.0 } //XE4 or later
    {$LEGACYIFEND ON}
  {$IFEND}

 

Why not just use IFEND for all?

{$LEGACYIFEND ON} switches XE4+ back to the old behaviour. (Didn't know that, it never mattered to me, as I always had to support some older Delphi version anyway.)

Edited September 5, 2023 by dummzeuch

[Uwe Raabe 1890]

2 hours ago, Vincent Parrett said:

I usually have something like this so I can have one inc file that supports versions before and after XE4

The IFEND works in all versions. LEGACYIFEND ON only makes XE4+ accept only IFEND, too. That might be helpful to write code compatible with versions before XE4 when written and tested with newer versions only. So it is more like a safeguard for the developer, but code written like before XE4 will also compile in XE4+ without that LEGACYIFEND directive.

Edited September 5, 2023 by Uwe Raabe

[Anders Melander 1639]

As far as I remember it had something to do with some pre-Delphi 6 version attempting to parse the {$if ...} even though it was protected by a {$ifdef CONDITIONALEXPRESSIONS}.

It could also just have been the fact that {$if CompilerVersion...} doesn't work above the first uses clause...

 

Anyway, it doesn't really matter anymore. It just struck me that there was a reason why the feature didn't gain more use - from me at least.

[Remy Lebeau 1260]

7 hours ago, Anders Melander said:

So, can anyone remember which version of Delphi broke that scheme?

 

It's not broken now, but I'm certain that there was a version after Delphi 6 that somehow broke {$IF} so it couldn't be used if backward and forward compatibility was needed.

I don't remember the specific version, but I know there was a time when the compiler had problems with the evaluation order of {$IF} and {$IFDEF}, I think that was around the early Kylix days, so would have probably been around Delphi 6-8.  But that is just a guess...

[Remy Lebeau 1260]

4 hours ago, dummzeuch said:

Why not just use IFEND for all?

I also use {$LEGACYIFEND ON} in Indy for XE4+ versions.  Helps the code remain backwards compatible with earlier versions by forcing the compiler to not accept {$ENDIF} to close {$IF}. The compiler can run into issues when you have nested {$IF} and {$IFDEF} blocks but don't use {$IFEND} consistently, which can trigger error E2029, as mentioned in the {$LEGACYIFEND} documentation (and I've run into it before).

[Ian Barker 17]

On 9/4/2023 at 10:10 PM, Tommi Prami said:

Can anyone figure out why Embarcadero could/would/should not publish rtl, compiler etc versions and codename for the beta, just as they include first outsider to the beta test?

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.

[Dave Nottage 493]

1 hour ago, Ian Barker said:

as long as they did not refer to or expose any functionality which was specific to version 12

What about when a third party has both source code changes that make the code compatible (i.e. doesn't refer to new functionality), in addition to having code that does take advantage of new features (i.e. both kinds of changes in the same release)? It would seem to exclude them from doing anything at all, or at least hold off on the latter part, since it would be a breach? I wonder how many this would apply to? I know from the changes going from Delphi 10.4 to Delphi 11 that it would definitely apply to me.

 

[Uwe Raabe 1890]

During the beta I use private forks of the public repositories to store all the changes. On release date the fork is merged into public. I don't distinguish code I may publish or not.

[Dave Nottage 493]

31 minutes ago, Uwe Raabe said:

During the beta I use private forks of the public repositories to store all the changes. On release date the fork is merged into public. I don't distinguish code I may publish or not.

Isn't this statement a breach of the NDA? 😉

 

If I was participating (in theory, because I am not admitting either way), that's what I'd do, because I think the conditions are still fuzzy 🙂

 

[Tommi Prami 123]

While back I was pondering this situation again.

When new Delphi comes out, it takes sometimes quite a long time we get it into the production, because have to wait some of the dependencies to release updates. We can fix those ourselves, but not always. IT can be pretty hard to familiarize the third party code that needs a fix (it maybe somewhat obscure considering the problem how to actually fix it).

So I would propose that there would be some faster channel among of the Beta testers. Many of those in Beta provide some Open/Closed Source -code to others in community.

If there would be common place to exchange those fixes, privately, and preferably also chat about how the beta is going etc, this would guess also lead to better bug reports and so on.

 

Something like private Discord-server/channel (Or something similar) and/or forum similar to this. I mean that now people and companies doing beta test are separate islands of information that does not spread. And I think it would, in long run, help everyone.

 

-Tee-

 

[Uwe Raabe 1890]

7 hours ago, Dave Nottage said:

Isn't this statement a breach of the NDA?

You mean, that I am part of the beta? That is already known in public IAW Embarcadero: TZipFile Improvements in Delphi 12

[Remy Lebeau 1260]

14 hours ago, Tommi Prami said:

So I would propose that there would be some faster channel among of the Beta testers. Many of those in Beta provide some Open/Closed Source -code to others in community.

If there would be common place to exchange those fixes, privately, and preferably also chat about how the beta is going etc, this would guess also lead to better bug reports and so on.

 

Something like private Discord-server/channel (Or something similar) and/or forum similar to this. I mean that now people and companies doing beta test are separate islands of information that does not spread. And I think it would, in long run, help everyone.

Embarcadero already has private channels/forums available for its beta testers and MVPs/TPs.

[Tommi Prami 123]

8 hours ago, Remy Lebeau said:

Embarcadero already has private channels/forums available for its beta testers and MVPs/TPs.

Interesting...

I've been in beta couple of time in past 20+ years, and first time I hear about this.

Edited October 24, 2023 by Tommi Prami

[Uwe Raabe 1890]

There are different levels of beta testers...

[Tommi Prami 123]

34 minutes ago, Uwe Raabe said:

There are different levels of beta testers...

Then this system should change, I think... 

 

-Tee-

[salvadordf 32]

FYI : I'm not a beta-tester but the latest Skia4Delphi code available at GitHub includes {$IF CompilerVersion >= 36} several times.

Edited October 25, 2023 by salvadordf

[Ian Barker 17]

On 10/25/2023 at 4:10 AM, salvadordf said:

FYI : I'm not a beta-tester but the latest Skia4Delphi code available at GitHub includes {$IF CompilerVersion >= 36} several times.

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

[Ian Barker 17]

On 10/24/2023 at 4:31 AM, Tommi Prami said:

Then this system should change, I think... 

 

-Tee-

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.

[Tommi Prami 123]

9 hours ago, Ian Barker said:

I think it could have been better worded - it's not that there are different levels of beta testers as such.
...
Ian.

That is perfectly OK. Especially if Embarcadero knows that this person/company is using Delphi certain  way, change possibly breaks it or makes better, let them test first etc...

That is smart I think. Beta should be, at first for small group of people, to keep amount of messages and bugreports at bay etc...

I was referring to the communication channel/channels to take full advantage of the Public Beta. Also if there would be private repository for Beta testers of open code that is ready for the future release. Would make testing with everyone's own products faster and more efficient.

Edited November 6, 2023 by Tommi Prami

[Vincent Parrett 657]

FWIW, all my open source delphi projects at https://github.com/VSoftTechnologies/  support Delphi 12.

[Tommi Prami 123]

JCLK and JVCL should support D12 in their repository received commits today.