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
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/v6220.127.116.11805
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
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
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
(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? "18.104.22.168"? "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? "22.214.171.124"? "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
Problem is: I cannot sort the version field in Bugzilla, see
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.
Haven't added this to the Target Milestone field (saved me 10min and people
searching for Target Milestones are normally already familiar with the
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".