I have noticed some similarity and even some duplicates of version numbers between products, or how some start with 0.1 and some are 1.0.x etc
Can you share the “key” to how these versions are tracked?
Something like: Major Product Release (dot) Minor Feature Update (dot) Security Patch (dot) New Feature?
And when a device has been “abandoned” for the new v2 do we expect to see FW versions pick up where v1 ended?
Some examples I have noticed:
Cam Outdoor v1 - [4.17.4.418]
Cam Outdoor v2 - [4.48.4.418]
similarity
Cam Pan v2 - 4.49.3.2864 (November 2, 2022)
Cam Pan v3 - 4.50.0.3405 (January 10, 2023)
picks up where v2 stopped
Cam OG & Cam OG Telephoto - 1.0.59 (February 13, 2023)
have the same version and release date but 2 different files
Cam v3 Spotlight - 0.0.0.16 (November 22, 2021)
Has only 1 release and is such a small decimal
I honestly do not know if there is an organized standard to the version numbers, other than that they are sequential and mostly separate per different device/hardware.
I think it’s mostly tracked internally. the lowest numbers on the far right will be smaller iterations that change more rapidly as the devs are testing new minor changes. This is why we can see large jumps between public releases. But more than that I really don’t have any knowledge.
Not as much as I should and half as much as I claim.
I believe Wyze to be employing a locally customized version of a Triplet Semantic System. The locally customized bit is the addition of a fourth set in the second position.
The first position is standard for the Major Build Structure, perhaps identifying the base language and\or OS syntax from which it originates. The second is what I suspect is the custom numerical set Wyze has added to identify the cam
However, it isn’t a perfect correlation as this doesn’t fit for the * V1 and V2 which seemed to go by a different standard which they kept thru their life span before adopting the current standard.
The third set usually represents the Major Change version that would introduce significant changes to security protocols, overall firmware functionality, or significant feature additions. For example, when the V3 underwent the firmware update that added the security protocols requiring a factory reset to revert (4.36.10.xxxx), we saw the warning appear in the Release Notes & Updates Firmware Page and a jump from .9 to .10
The last set is most likely the final internal build iteration to be logged before that build version was released for Beta or Production update.
Because many of these cams are built on the same OS platform and code language, and because they share very similar components and functions, it is expected that the firmware numbers would progress in parallel to each other. It would be inefficient for Wyze to only update one particular cam firmware when others have nearly identical code sets for the same or similar components and functions. Instead, they usually come out together with similar version numbers because the Devs apply the changes, upgrades and patches to every firmware set that needs it… write the code once, paste it in to each cam firmware that needs it. You can see this in the progression of the WCOV1 and WCOV2 which are different only in the cam identifier set. The base station follows their progression with only the final build version different which is to be expected since it is a different hardware platform. The WCV3, WCPV2, and WCV3P are also released together and share all but the cam identifier set.
Thanks so much! I think this kind of info would help create deeper trust and understanding. More transparency is a good way to build understanding and proper expectations in many cases.
Firmware versions change kind of per product, but generally, the last number is going to be our internal build number. Second to last is the major version and then the first two are product-specific.
Annoyingly, that last number can’t exceed 4 characters for legacy reasons. So expect it to roll over back to 0000 at some point.
