Release of patches for X#

[leon-ts]

Hi,

I have to raise this topic, because at the moment for the enterprise (FOX subscriber), which I represent, it has become critical.

I will describe the background.
As most of you probably know, transporting a real application from VO to X#, which is currently in production, is not an easy task. Customer requests come in and you are forced to synchronize the VO code with the X# code so that when you release the same application in X# it contains all the latest changes.

For this reason, my team chose this summer, because traditionally in the summer business activity decreases slightly (fewer requests from customers). We started in late spring and by the end of the summer we had converted two of our three biggest apps to X#. During testing, two serious problems were found that we cannot get around (stack corruption when using some types of structures and the use of the M-> prefix in codeblock expressions). For these problems, I created git tickets and the X# developers have successfully fixed it. But there is still no official version with this fixes. The last official version 2.8c was released in early July this year.

At the same time, in view of the increasingly complicated synchronization between VO and X# projects, we decided to implement all the latest requests from customers only in X#. Otherwise, we would have to postpone the migration to X# until next summer. But by that time, a huge number of changes have accumulated in the VO project that cannot be trivially transported. As a result, all current work continues only in X#. But we cannot even conduct full-fledged internal testing, let alone distribute the version to customers.

In this regard, I have an acute question about the release of critical fixes for X#. It is good practice to promptly release critical patches that apply to officially released versions of the product. And innovations and fixes of less critical problems can be postponed until the next official version. We are all developers and we understand that adding innovations can bring new hidden problems. Therefore, it is important to release critical patches specifically for the released version, the less critical problems of which are already known and the developer has somehow solved them. Is it realistic to have such a process for releasing X# versions?

We waited for the version in August (it was not critical yet). Then in September (there was news that it would probably be at the end of September). That did not happen. There was also a message that this will not happen this week either.
At the moment, my team does not understand when the fixes in X# will be released. In this regard, there is also a concern that when we release our product and some serious problem related to X# is found in it, then there is no certainty that we will receive a fix within a reasonable time. This is a matter of grave concern to us.

Best regards,
Leonid

[robert]

Leonid,

Thanks for your message, and I understand your concerns.
We are finalizing the 2.9 release, but as a software developer you will understand that sometimes during QA checks short before the release you will find blocking issues that delay the release.

At this moment, there are NO blocking issues in the compiler and NO blocking issues in the runtime.

However we also made significant changes to the VS integration, some of which were triggered by issues reported by you.
Some of the other issues had to do with overall performance of the X# Language Integration inside Visual Studio.

During testing we found that our VS integration was not working the way we expected and this has blocked the release:
Considering the sometimes "heated" discussions here about Visual Studio and Microsoft in General, we decided that it would not be a good idea to release the 2.9 build until this new issue is resolved.

We have very good faith that we found the cause of the problem, but I want to be absolutely sure before release.
We plan to create an other (internal) installer and have it tested. If the issue is indeed fixed then we will release 2.9 next week.

Robert

[leon-ts]

Robert,
Thanks for the clarification! The situation is quite understandable.
In my post, I just wanted to discuss a solution that would allow major product innovations not to delay smaller, but equally important improvements and fixes. For example, output major improvements in a separate branch.

However we also made significant changes to the VS integration, some of which were triggered by issues reported by you.

Yes, I am very grateful to you for that. I have been closely following XSharpPublic's git tickets and see how much work you do!

Best regards,
Leonid

[Chris]

Hi Leonid,

I am sorry, that's probably my fault, I would had sent you compiler/runtime quick fixes earlier, but I have probably mixed up your accounts.
Are you also using another forum account here?

.

[leon-ts]

Hi Chris,
On this site and on git, I use the same account (leon-ts). Email also matches.
If there is a high probability that there will be a full-fledged official version next week, then I will wait for it. But if difficulties arise again (anything can happen), then I will ask you to send me some patch (if possible). While waiting for next week.
Thanks!

Best regards,
Leonid

[Chris]

Hi Leonid,

I will contact you privately.

.

[Kees Bouw]

I think releasing patches between versions would be a good thing, if possible. For example, the problem with declaring a variable "AS ARRAY OF <something>" which is overwritten by the windows form designer was fixed on Sept. 15 (according to Robert) but I have to wait a month until the new version is released. I have to manually restore this line several times a day. Also the automatic creation of a .bak file could maybe be done in a patch. Of course every user has his own ideas of what is urgent but in general the concept of patches between versions is appealing.

[robert]

Kees,
We'll pick up the quick fixes in the not too far future.
Unfortunately both issues that you reported are part of the VS integration and we have been making A LOT of changes in this area recently, making it difficult to send out patches for this particular part of the product.

Robert

[VR]

It might help if it would be possible to split Runtime, Compiler and VS-Integration into separate setups and release cycles. I assume, that many of the changes of the runtime are independent of Compiler and VS-Integration and could therefore released more often. I don't know if this is also possible for Compiler and VS-Integration.

Of course it would be nice to get patched versions also the vs-integration, but that comes with the cost of back-porting and testing the changes to the old version(s), that is very time-consuming when a lot of changes are made to the code base.

[Chris]

Hi Volkmar,

We have discussed about making the compiler and runtime available as nightly builds, hopefully this will be implemented in the not too distant future. In the meantime, we often do send quickfixes directly to customers who request them, usually runtime fixes which are the easiest to send and deploy, but also for the compiler when necessary. That usually happens for particular bugs which cause problems to specific apps, not just general updates