What is the reason for the delay in the release of Experimental Version?

[ghost1372]

What is the reason for the delay in publishing the next experimental version? Why is everything unplanned?
It is mentioned in the documents that an experimental version will be published every month.
But no new version has been released since August 10

[andrewleader]

Thanks for asking. Our docs state that we are targeting monthly, key word being "targeting". We're still in our early phases and simultaneously releasing both experimental and preview releases every month is too taxing on the team right now. The 1.0 Experimental 1 release will be the last experimental release of 1.0, but we'll have another experimental release after 1.0. Right now for 1.0 we're focusing on preview releases, and we'll be releasing more preview releases before 1.0 Stable.

[andrewleader]

Yes, the next preview release of 1.0 will have the updated Windows 11 visual styles. We can't share when that next preview release will be released, but hopefully soon, since our last preview was 18 days ago.

[ghost1372]

thank you so much

[nickrandolph]

@andrewleader can I make a suggestion that going forward you evolve the use of the experimental channel and/or setup a nightly build channel.

Right now it seems that there's too much effort required in order to push new builds to the experimental. You need to create release notes and make sure there's some level of stability, despite the warning already placed on this channel about it being experimental.

My suggestion would be either (or both) to:

• Significantly reduce any overhead that currently exists for the experimental channel (eg docs, stability testing) and simply publish new builds as and when key features are added.
• Setup a nightly build channel - this would literally spit out new builds whenever changes are merged. It could be a literal nightly build, or it could be one that's only generated if there have been changes merged.

There needs to be more accountability and ability for the community to provide feedback. The current preview builds are no more stable than the experimental builds. They're definitely not a good indication of features that will/won't ship. For example on the AppWindow, the ability to fix the size of the window seems to have been dropped between preview1 and preview2.

[andrewleader]

@nickrandolph yep, we would love to do all of that. We're attempting to do the best we can, but haven't been able to publish as many releases as we would like. I'm not sure publishing experimental releases without any validation would help if the builds don't actually work... we still have some ways to go till we have enough automated testing to give us some confidence without manual testing.

Right now we're heads-down focused on finishing 1.0.

[nickrandolph]

@andrewleader if the team isn't comfortable with doing nightly builds, with the inherent instability that goes with this, then there needs to be some self-introspection about the commitment to moving to being OSS.

You're stating that stability/validation are the key reason not to do nightly builds? However, there are numerous OSS projects, including Microsoft lead projects like the Windows Community Toolkit, that are able to do nightly/PR based builds. This is done with the full understanding that nightly builds are made available "as-is". In other words not supported, no go-live license, no guarantees that features/fixes will work.

I get that this is a change in the philosophy of how WinDev ships but I would argue that if the team is serious about building deeper engagement with the community going forward, producing nightly builds would seem a logic (and very low cost) step forward. This does assume you're doing nightly/commit/pr based builds.... the team does do this.... right?