Has Particle mentioned anything about their expected timeline or plan to get the Particle.io firmware to 1.0? I’m trying to understand how Particle views the fact that major point release versions (0.7.0 for instance) are tagged with the note 'This is a Release and may be used for production". Should we not view getting to 1.0 as a signal that Particle’s firmware is ready for production? Does Particle hope to get to 1.0 soon?
Great question Kevin.
There are, in fact, many production fleets out in the world running versions as early as the 0.5 line and as recent as the 0.8 prereleases. Each company does its own testing on its own development devices before releasing to the broader fleet.
That said, we do have plans to release 1.0 this year to signal more broadly to the world that the Particle Device OS is a stable system on which to build an IoT product.
12 Likes
@incorvia, just FYI for software release naming conventions, Particle uses a custom one detailed here: Confused about Software Release Life Cycle naming conventions
We use 0.7.0 quite successfully, although depending on what you’re doing other firmware versions might be a better fit. With the Electron, we have a blocking issue with 0.8.0, Electron power-on connectivity issues with 0.8.0-rcX, and Issues with firmware 0.7.0 details an issue with 0.7.0 on Photons.
Thanks for taking the time Zachary, it makes me glad to know that Particle is trying to push to get to 1.0 by the end of the new year. While many people are using it in production, it would be nice to see Particle give voice to the confidence they have. It will only help us, the developers, feel more confident.
2 Likes
I think you are putting too much importance on the less than 1.0 aspect of the version.
1 Like
I disagree. Syntax conventions are important. Who among us would recommend eating chicken described as “raw”? Or “burnt”? By convention, having a <1.0 release says that the authors do not yet feel comfortable enough in their product to say “this is done and fit for service”, i.e. the meat is undercooked. Thus, due diligence demands that people with commercial responsibilities dig into why Particle is currently <1.0.
That being said, if you read the forum posts from @zachary you can see he has clearly articulated Particle’s vision of how they intend to do release schedules. It’s different from the SRLC convention and so thanks to his explanations I have more confidence in <1.0 releases than I would otherwise.
3 Likes
I would think anyone who feels a firmware version of “0.7” somehow translates to “raw” or “burnt” doesn’t understand software naming conventions and is too much a victim of marketing departments.
That said, I suppose this thread does go to show Zachary is right about releasing 1.0. Not because the number means anything, but because it doesn’t, so why not do it? He could have called version 0.7 version 286 or version Avogadro’s number if he’d wanted. It wouldn’t change anything.
3 Likes
Version 1.0 as a milestone
The free-software and open source communities tend to release software early and often. Initial versions are numbers less than 1, with these 0.x version used to convey that the software is incomplete and remains a work in progress.Version 1.0 is used as a major milestone, indicating that the software is "complete", that it has all major features, and is considered reliable enough for general release.[21][22] A good example of this is the Linux kernel, which was first released as version 0.01 in 1991,[26] and took until 1994 to reach version 1.0.0.[27]
In MY experience, anything less than 1.0 means that users should expect that major breaking changes are possible and that the API is unstable. After 1.0 the API is considered to be stable and reliable. There also may be major known bugs or incomplete features. We could go down a path of arguing about this like moral relativism but the question still stands, either Particle.io intends to be intention revealing with their choice of 0.7.0 or they don't tend to be and understanding that was the purpose of the question. I would argue, like Kubark24 has before, that following conventional version formats unconventionally only leads to confusion.
It's like if you were reading some new review site and you saw something got 3 out of 5 stars and thought.. ok they only thought this was mediocre, but then you read their about page and it says that "We give a star everytime we ate here and the food was perfect!" .. Ok.. you can do that, but that's not how people usually think of it...
I'll also add this about Semver
If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.