maemo.org Bugzilla – Bug 3747
4.2008.36-5 SDK is listed under 4.1.1
Last modified: 2008-10-02 14:15:42 UTC
You need to log in before you can comment on or make changes to this bug.
The latest update (4.2008.36-5) is listed under Maemo 4.1.1 in the repository. This presents some . . . issues, as the community has been working under the assumption that 4.2008.30-2 was 4.1.1. Is 4.2008.36-5 actually 4.1.1, or is this a simple repository issue that could be fixed easily? This is a _very_ big issues for bugs.maemo.org if 36-5 is, in fact, 4.1.1, as the target milestones and versioning will need a major overhaul. . . . User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US) AppleWebKit/525.18 (KHTML, like Gecko, Safari/525.20) OmniWeb/v622.2.0.104805
Uargh. We've been tagging 4.2008.30-2 as 4.1.1 everywhere, see the maemo wiki at https://wiki.maemo.org/Template:Release_history_table or Wikipedia. Please don't increase confusion, and don't make me waste another hour by changing 4.1.2 to 4.1.1 and old 4.1.1 to something I can't even imagine a name for... 4.1.0.1?
Guys, the first Diablo SDK was called maemo4.1. Now, we have another release to be announced called maemo4.1.1. Is there a problem with that? I dont think so. When the 1st SSU was released (in August), there was no corresponding SDK update. Now, if we have to go by the community decided version number, then the right way to do it is to re-create the entire release.
The problem seems to be that for whatever reason Andre, Ryan and others expected to match every SSU with a Maemo release version. But in my opinion this is not very sustainable since (hopefully) there will be more and more SSU and just a few of them will actually carry any changes in the SDK versioning. To tell you the truth, I still don't understand what is the real problem here.
OK. I should realize that http://repository.maemo.org/stable/4.1.1/ really *only* provides the SDK. I think I can survive that, though I still think it's confusing ("Ah, so SDK 4.1.1 was released with Maemo 4.1.2").
(In reply to comment #4) > OK. I should realize that http://repository.maemo.org/stable/4.1.1/ really > *only* provides the SDK. > I think I can survive that, though I still think it's confusing ("Ah, so SDK > 4.1.1 was released with Maemo 4.1.2"). > I would suggest not to number the SSU similar to the SDK, like for eg: SSU-1, SSU-2.. if numbering is indeed required.
(In reply to comment #5) > I would suggest not to number the SSU similar to the SDK, like for eg: SSU-1, > SSU-2.. if numbering is indeed required. Well, I have to put something into the "Version" field in this Bugzilla, and the Target Milestone field. A "4.1-Update2" might work if we really wanted that. (I've used the word "SSU" twice in a bug report and was asked what it means, so I normally avoid SSU.) PS: Seems Bugzilla mail now works for you. Cool. :-)
After a chat with Soumya: - http://repository.maemo.org/pool/maemo4.1.1/ is correct now since that is the SDK repository and there was no SDK release between 4.1 and this one. - We were not aware/conciouss that the Bugsquad took the initiative of naming 4.1.1 as a target milestone corresponding to 4.2008.30-2. Sorry about that. Next's time let's agree on something instead of making assumptions. The last I remember agreeing with Andre was to call "4.1+" any maintenance updates coming after a proper release like Diablo was. - We are not even certain that SSU updates of a PRODUCT (versioned with the "4.2008.30-2" schema) need to be identified one by one with the "4.1.1" schema corresponding to the base OS. What if one day we get updates every week? What if one day one OS serves different products with different configurations? - We do see the work that would imply to make the changes from "4.1.1" to... what? "4.1.0.2"? "4.1+"? It is your choice to pass this time (not the end of the world), do some database automagic changes (is it possible?) or do manually the work. From our side there is not a requirement to repair the damage and we think there are bigger issues that deserve a priority instead of this one. For all these reasons we think this is something like a WORKSFORME, even if we see our part of responsibility in the problem. What do you think?
(In reply to comment #7) > - We were not aware/conciouss that the Bugsquad took the initiative of naming > 4.1.1 as a target milestone corresponding to 4.2008.30-2. Sorry about that. > Next's time let's agree on something instead of making assumptions. The last I > remember agreeing with Andre was to call "4.1+" any maintenance updates coming > after a proper release like Diablo was. Right, my fault - forgot to inform you. The reasoning behind was that tracking all the SSU updates as "4.1+" makes it much harder to verify fixes, and impossible to provide a basic ChangeLog functionality (query for public bugs that have Target Milestone set to 4.1.2 [SSU-2], for example). > - We do see the work that would imply to make the changes from "4.1.1" to... > what? "4.1.0.2"? "4.1+"? It is your choice to pass this time (not the end of > the world), do some database automagic changes (is it possible?) or do manually > the work. From our side there is not a requirement to repair the damage and we > think there are bigger issues that deserve a priority instead of this one. I'd like to see feedback by others how confusing they think the current situation is, and if they prefered to maybe have "4.1-Update2" in Bugzilla instead of 4.1.2. Ryan, Karsten? Moving to Bugzilla component.
Would it be possible to use the Control Panel/About product information? So instead of SSU-1 on top of 4.1 or something we could just use "4.2008.30-2" or "Diablo:4.2008.30-2" and then people will be able to identify their version and the version where the bug was fixed and there would be no need for a version lookup table to match week versions and 4.x numbers.
Marcell: That's what X-Fade, Ryan and me were discussing on IRC just a few minutes ago. Problem is: I cannot sort the version field in Bugzilla, see https://bugzilla.mozilla.org/show_bug.cgi?id=65317 . So 3.2009.1-2 would be listed before 4.2008.36-5 in the Version field (but not in the Target Milestone field, haha - we have a sortkey there ;-( ). I think I'd prefer something like "4.1-Upd1 (4.2008.30-2)" for versions and target milestones. Ugly and long, but much more failsafe, and renaming all this should only take 10 minutes.
Well, part of this issue stems from the new branding. Maemo 4.1.1 != Maemo SDK 4.1.1
(In reply to comment #11) > Well, part of this issue stems from the new branding. > > Maemo 4.1.1 != Maemo SDK 4.1.1 No, but the base OS and the SDK share the same content and therefore would share the same version. Maemo != OS2008 is a much clear comparison.
Except for the Website and Development Platform components I have added the "version.yyyy.ww-patchlevel" string to the Version field in Bugzilla. Examples: 4.1 (4.2008.23-14) 4.1.1 (4.2008.30-2) 4.1.2 (4.2008-36-5) Haven't added this to the Target Milestone field (saved me 10min and people searching for Target Milestones are normally already familiar with the versioning scheme). I hope this makes it more clear to report and search against a correct version. Closing as WORKSFORME - I don't think we will find a wonderful concensus that turns this report into something that I'd call "FIXED".