Bugzilla – Bug 11805
Firmware identifying number should include 3 levels of detail (ex: 8.1.2)
Last modified: 2009-10-05 14:36:06 UTC
Currently our firmware for Fab4/Jive is identified by only the first 2 numbers of a release-- example: 7.4 r5265. We need the full 3 number identifier for our releases-- example: 7.4.0 r5265. This will help in discussing firmware internally as well as with customers. It will also assist in training support staff. I propose this change for both Fab4 and for Jive.
Starting with 7.0, SC does the same thing (sort of): 7.0->7.0.1->7.0.2... The first new dot release is always only 2 digits and the rest are 3. I'm not saying I agree with this, just pointing it out.
For the purposes of downloading plugins and applets, can we make this 7.4.5265 for your example case. This means that every build will have a unique number which can always be compared to work out which is newer. If you drop the build number then nightly releases can't be cross referenced to the release which makes deciding which is most up to date impossible.. (there's a module in SC which defines a numbering scheme and used for comparisions - it would be good if the firmware version could use it...)
We need at least 3 levels of version number (x.y.z) on top of the revision number. One approach would be 7.4.0.12345, but I think that the 7.4.0 r12345 works just as well. These are strings that can be compared anyway, we just need to be consistent with its use. So, I agree that for 7.4 we really need to call it 7.4.0 AND we should be using similar numbering schemes for firmware and software releases, IMO.
Sounds good. And to Triode-- I do not propose dropping the build number. Only making the version number more accurate.
Reason for raising is that I would suggest we should be using numbering conventions which match Slim::Utils::Versions for player firmware and SC versions and plugins/applets. This means we can use a constent scheme to compare and see which is newer. It also allows a single range check for the purpose of plugin/applet installation. This doesn't need to be the publically exposed version number but it should really be used internally. Taking an example - if I have an applet which works for 7.4 r2564 onwards then I want to be able to do a single range check to define whether the new applet should be installed. Having 7.4.0.2564 which moves to 7.4.1.2565 when 7.4.1 is released doesn't help that as its not compatible with the range check mechanism already defined in Slim::Utils::Versions.
My concern and input is entirely focused on our public numbering scheme.
I actually propose the opposite... Instead of trying to maintain SqueezeOS firmwares with somewhat-matching SqueezeCenter version #'s (Jive 7.4.0 + SC 7.4.0 for example), I think that the SqueezeOS firmware numbers need to be completely different than SqueezeCenter versions. We already have a very difficult time trying to keep them somewhat matched, and its really not important given the way we release the files. I'd suggest that when SC gets released at 8.0, we make a clean break and from trying to keep them with similar version #'s. Leave SqueezeOS firmwares at 7.4, and bump their version # only when it makes sense to the SqueezeOS product itself. Either way, this isnt really my arena -- I just build em :). This should be assigned to Dean to come up with a long-term game plan and then to Richard to implement in the SqueezeOS tree.
Squeezeplay and SqueezeCenter have a fairly tight integration and keeping them paired is basically essential. Either we keep the version number as is or we add finer resolution, but decoupling them is not really an option.
Dan: if we included the third digit and it was always the maximum number (i.e. 7.3.3 now) even though it was compatible with lower numbers, would that work for you?
Dean-- if you are referring to the two choices in comment #3, then yes I think that'd be fine. What I would expect then on release for SBT is the firmware would be called: 8.0.0 r6123. (made up build #) Do I have that right?
*** Bug 9930 has been marked as a duplicate of this bug. ***
I'll be using version numbers in this format: 7.4.0 r5265 Before the firmware is modified to support 3 digit firmware version numbers, SC and SN need auditing to make sure they won't break. I have and a quick look at the SC code, and that seems to only support 2 digit version numbers. Michael offered to look at this. A couple of weeks after the SC change, I'll change the firmware.
I might be wrong, but I yet have to find a line of code which would care about the number of number identifiers. The needs_update check is rather simple: if ( ( $firmwares->{$model}->{version} ne $cur_version ) || ( $firmwares->{$model}->{revision} > $cur_rev ) ) Which means we're forcing up/downgrades whenever the version changes. Is the plan of this bug to make this more intelligent, like eg. don't need an updated as long as we're in the same minor number (2nd)? eg. 7.4.0 -> 7.4.1 would _not_ require an update? Otherwise we're afaict fine.
Andy: Isn't this something you are already working on? Wasn't this needed for SqueezeNetwork?
I think SN will be fine, let's go ahead and do this. I think the only thing that would break is the temporary code to send Fab4/Baby nightlies from SN. It checks for filenames with: /^${type}_7.4_r\d+\.bin$/ So this would need updated to be 7.4.0 instead.
Michael, I double checked the code I looked at last week and your right, SC should be fine. I had misread it thinking the > condition applied to the version number, not revision. Thanks for looking, I'll change the firmware.
== Auto-comment from SVN commit #6994 to the jive repo by richard == == https://svn.slimdevices.com/jive?view=revision&revision=6994 == Bug #11805 Changed to use three digit version numbers.
Andy, I've made this change in r6994. Please update the SN temporary code as appropriate.
== Auto-comment from SVN commit #6910 to the network repo by andy == == https://svn.slimdevices.com/network?view=revision&revision=6910 == Fixed bug 11805 - support 3-digit firmware version
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.