So, banging away at a new library implementation, and bam
src/AdaRA8875_Test.ino:35:51: warning: ‘particle::Future CloudClass::publish(const char*, const char*)’ is deprecated: Beginning with 0.8.0 release, Particle.publish() will require event scope to be specified explicitly. Define PARTICLE_USING_DEPRECATED_API macro to avoid this warning. [-Wdeprecated-declarations]
Particle.publish(“AdaRA8875 Demo”,“RA8875 start”);
First, as a Sr Site Reliability Engineer - are you bloody kidding!!! Breaking changes in the firmware?? WTF?
In addition, the easiest way out of this pickle is not to disable the warning but actually adopt the “new” syntax which was always the prefered way to go, the compilers just have also accepted the “lazy” syntax of omitting the scope and relying on the PUBLIC default.
But the increase of users that just don’t care whether the events go public or not has lead to some unexpected sideffects (e.g. inadvertent subscribing to other peoples public events) and hence the scope will need to be provided (although I’d rather have changed the default to PRIVATE - and MY_DEVICES on the subscriber side - to keep the oblivious happy ).
Particle.publish(event, payload, TTL, scope) was always the prefered way and whenever we saw it without scope we suggested to add the PRIVATE scope to avoid spamming the public firehose. But if you must, just use PUBLIC instead.
BTW, as Kenneth said, 0.8.0-rc.X is a release candidate (hence the extension) and the release notes always warn about this
You guys miss the point. Breaking changes in compilation are extremely costly in the development cycle for companies. Reliability is obtained by a consistent ability to mesh old and new code and being able to roll forward and backwards with no breaking changes.
Breaking changes cost time and money, this is clearly not smething that development staff understand and I realize that - but revenue generation and not code is the deliverable for any programmer and breaking changes makes that harder
A lot of discussion went into this change. One of the reasons is that Particle::publish(const char*, const char*) defaults to a public event, viewable by everyone. By removing this overload, it forces developers to examine whether they really intended to publish this event publicly to everyone.
Very few people were intentionally using the public event stream, but since the number was non-zero we can’t just switch the default from public to private. On the other hand, a number of people are clearly unintentionally using the public events stream, and this seemed like the least disruptive way of coaxing people to choose which event stream they really wanted to use.
And this is why compilers have WARN. The problem with a breaking change, is now I have to go back through my code and change it to be compiled under v8 - here is the rub - Particle is about moving to market quickly, very quickly, and this isn’t in line with that.
Developers, not the implementation framework, are responsible for security. I should also point out that the documentation is oblivious as to if a token is required to subscribe to events or not from an account, in fact, the public vs private is not clear at all for all circumstances. I should never be allowed to subscribe to an event if I don’t have a token - again, documentation unclear.
Where is the discussion about cost in all of this for customers? You both realize not every company has development staff and has to farm this out? Imagine how many customers have scripts to program their particle, I’m sure not many of them take into account the firmware version when flashing chips …
For events that are marked public (by default or explicitly) the developer wants (or at least accepts) the event to be seen and subscribed to by others.
In what way would this be a breaking change? If you were unaware that your events were published PUBLIC by default and just subsribed to them without the explicit scope (also reyling on the default subscribe scope ALL_DEVICES) the “hidden”/“transparent” transition to PRIVATE/MY_DEVICES would not make any difference for 99+% of code out in the wild.
Especially when you state …
… I can even less see it as breaking change, since you obviously didn’t expect it to be PUBLIC to all in the fist place.
BTW, I’m only a privat individual contributing to this community, so I have no real influence on Particle decissions other than what they choose to pick up on.
This is not about why the code change was made from a technical or security standpoint.
My concern is about cost and Particle not being in line with the mantra that their system makes IOT enabled projects fast to bring to market. Breaking changes cost money for companies - nobody has addressed why this cost is justified - especially given the ability to push a WARN message on the compiler.
I’m still not sure where the breaking change you mentioned comes into play with my proposal
With that suggestion code would still build without change (unless flawed from the beginning by only applying one explict scope while omitting the other side - then it’s a bug in the application and not the framework).
That is true, but have you got any factual numbers how many people really used the default setting in order to get PUBLIC events published or is this just for the sake of an academic argument?
If that was what you’d find a viable solution Particle should have gone about the change.
Just for completenes since 0.7.0-rc.3 (August 2017) this warning was provided
warning: 'particle::Future<bool> CloudClass::publish(const char*, const char*)' is deprecated:
Beginning with 0.8.0 release, Particle.publish() will require event scope to be specified explicitly.
Define PARTICLE_USING_DEPRECATED_API macro to avoid this warning. [-Wdeprecated-declarations]
So the code still builds for all official realeases and before 0.8.0 will be officially released I’m pretty sure some extra updates will come.
Also noone will be forced to 0.8.0 if they have no way to update their code base to accomodate for the new syntax. But if they need to move on to 0.8.0 I’m pretty sure there will be bigger code changes (e.g. accomodating for newly added features) which will allow for these minor changes to be incorporated too.
All this is all a bit of a tempest in a teacup, but you are correct regarding breaking code.
This problem, which rears its head here on the forum quite frequently and many of us devs have come across, should have been dealt with much earlier, since users were often coming across the problems of misusing the function vis à vie scope.
Concerns like yours are why these pre-release updates are published, so comments from the developer community may influence the official updates.
Q.E.D. devs should stay current on firmware updates.
Without having gone in-dept as to what the actual issue might be…
What’s this ‘revenue impact’ you’re mentioning? In the time it took to write all these comments, the changes could’ve been made to accommodate the minor edit in a pre-release version. The change was documented in the topic linked to by @BulldogLowell above.
This version isn’t final and open to discussion. You’re not being forced to use it, and if you do want to, you’ll know that’s a change you’ll have to make, should you choose to upgrade to it when it’s released.
If you don’t check the code you’re pushing to your clients, “you’re gonna have a bad time”. If you’re using a script to compile/upload, and can’t be bothered to try the latest versions of firmware, then simply don’t use them?
I agree breaking code should be handled carefully, but can’t really see the big issue here.
All my students ran into this problem today using firmware 0.70 and it caused a normally well structured class to become quite messy as the error message in the web IDE did not contain anywhere near enough info to resolve the issue. More than 8 error occurs now when executing this official example from CLI.
How can I post a pull request on this one so I can can prevent this from happening to other educators?