Bug 3747 - 4.2008.36-5 SDK is listed under 4.1.1
: 4.2008.36-5 SDK is listed under 4.1.1
Status: RESOLVED WORKSFORME
Product: maemo.org Website
Bugzilla
: 4.1
: All All
: High major (vote)
: ---
Assigned To: Andre Klapper
: Ferenc Szekely
: http://repository.maemo.org/pool/maem...
:
:
:
  Show dependency tree
 
Reported: 2008-09-29 23:11 UTC by Ryan Abel
Modified: 2008-10-02 14:15 UTC (History)
7 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Ryan Abel (reporter) maemo.org 2008-09-29 23:11:41 UTC
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
Comment 1 Andre Klapper maemo.org 2008-09-29 23:17:22 UTC
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?
Comment 2 Soumya nokia 2008-09-30 10:23:26 UTC
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.
Comment 3 Quim Gil nokia 2008-09-30 10:35:51 UTC
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.
Comment 4 Andre Klapper maemo.org 2008-09-30 11:24:40 UTC
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").
Comment 5 Soumya nokia 2008-09-30 11:30:12 UTC
(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.
Comment 6 Andre Klapper maemo.org 2008-09-30 11:36:41 UTC
(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. :-)
Comment 7 Quim Gil nokia 2008-09-30 11:39:09 UTC
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?
Comment 8 Andre Klapper maemo.org 2008-09-30 12:00:24 UTC
(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.
Comment 9 Marcell Lengyel maemo.org 2008-09-30 12:13:09 UTC
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.
Comment 10 Andre Klapper maemo.org 2008-09-30 12:28:35 UTC
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.
Comment 11 Ryan Abel (reporter) maemo.org 2008-09-30 12:31:08 UTC
Well, part of this issue stems from the new branding.

Maemo 4.1.1 != Maemo SDK 4.1.1
Comment 12 Quim Gil nokia 2008-09-30 13:05:25 UTC
(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.
Comment 13 Andre Klapper maemo.org 2008-10-02 14:15:42 UTC
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".