Stop pushing non-GA versions onto the release channel

[marcelstoer]

I'm involved in a project that offers various Arduino-based open-source applications. For many of our users this environment is new and they heavily rely on our documentation for things to "just work".

We clearly state that we do not recommend installing non-GA versions of this platform through the Boards Manager. Yet, when the Arduino IDE notifies users about available updates many are all too happy to install even betas. Needless to say that this causes extra support effort for us when things fail because of that.

I do understand the need for early feedback on alpha, beta, and RC versions. However, I think it wrong to push those versions onto the official release channel. Thanks for (re-)considering the issues this causes for downstream projects.

[abachman]

Amplifying this request.

The 2.5.0 beta releases break compatibility with the ArduinoHttpClient library (relevant issue here: arduino-libraries/ArduinoHttpClient#48) which breaks users' code for us (adafruit) with the https://github.com/adafruit/Adafruit_IO_Arduino library.

For now we're just telling people to downgrade, but it means every single person who starts a new ESP8266 Arduino project has a broken project by default.

[d-a-v]

This change was made some time ago and this error was never reported.
Without this beta release, this error wouldn't have been noticed and would have been deployed in the next stable release.
The reason of these beta releases is to have a chance to be tested.
The json file for the arduino installation shows a version with -beta in its name. Previous RC versions had -rc and we changed it to make it more clear that a stable version is not beeing installed, thus issues might appear.
We understand your concern.
We are currently discussing of better ways for next releases.

About the above issue, I changed WiFiClient::flush() signature and we can revert. This change was made to report more status to users. This was a minor change since the original code was returning void. I never thought one would return a void function inside another void function (even if it could be useful in some case).

[devyte]

@abachman that is an entirely different issue from what is being discussed here. Having said that, I'll comment about it here anyways, and if you wish to discuss further, please look me up in gitter.
C++ allows a void function to return, as long as the returned type is also void. There are reasons for this, most prominently templated functions. However, just because the language allows something doesn't mean that it should be used without reason, and I think your case doesn't have a reason, because in this:

virtual void flush() { return iClient->flush(); };

your intent is to simply forward the call to the underlying iClient.

I think you wish to maintain compatibility across cores. There are several ways to semantically express your intent, but I suspect you wish to keep the void return type of your flush, so I think the clearest way to express that is this:

virtual void flush() { (void)iClient->flush(); };

So no return type for your outer flush, and whether the inner flush has a return type or not, it is explicitly ignored.

[devyte]

@marcelstoer I understand your concern, but I consider that new users need to be educated and made aware. And let's be honest: "beta" is a well known term in 2018, and like @d-a-v said, it's very visible when selecting a version.
You said that you clearly state that you don't recommend installing non-GA versions. That's a start. New users must start by reading the documents, and warnings must be explicit there. Any new user who ignores that and runs into trouble deserves his fate and should be directed to read the docs.
To reduce your support effort, I suggest requesting that the core version being used be included in the support request, if you're not already doing so. Then you can filter requests immediately. We do something similar here with our issue template and issue policy doc.

Personally, I think that the linked issue above, which makes the warnings even more explicit, is the correct approach.

We've discussed alternatives internally, and the decision is to maintain status quo for now. However, that isn't set in stone, and we'll likely revisit the idea of a second release channel for betas in the future. That will be a while, though, and before it happens, at the very least there are some prerequisites to be met, e.g.: #5480 , among other things.

I'm closing this for now.

[abachman]

@d-a-v there are a couple problems we've hit with the Arduino workflow in this scenario. First, the -beta tag on the release version doesn't show unless you explicitly select a version in the Arduino boards manager

And second, users who don't know that -beta tagged minor point releases may break existing code may not know to not pick the most recent release when initially installing.

@devyte The connection to the "don't publish beta releases into the Arduino release channel" issue is that a minor release of a core Arduino library broke an API that other library implementors relied on. We rely on ArduinoHttpClient and that library relies (in our case) on the esp8266 board support package. We can submit patches to the ArduinoHttpClient library, but it's tricky since other Arduino HttpClient compatible network libraries (e.g., Ethernet, ESP32, WiFi101) didn't change their implementations, so code that was previously compatible would have to include exceptions for just the ESP8266.

It's not world ending, just surprising since this library used to conform to the common API. And I honestly don't know whose responsibility it is to describe or maintain the Arduino HttpClient API and code that implements / uses it. We happen to be consuming both for adafruit/Adafruit_IO_Arduino so mismatches are hard to navigate.