529700 - Document how users should handle extension upgrades wrt versions included in SeaMonkey

Status: VERIFIED WORKSFORME

(SeaMonkey :: Project Organization, defect)

Description

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6pre) Gecko/20091118 SeaMonkey/2.0.1pre - Build ID: 20091118000804

Current Sm 2.0.1pre nightlies are shipped with DOMi 2.0.3 instead of 2.0.4

Reproducible: Always.

Steps to Reproduce:
1. Install the latest Sm 2.0.x nightly.
2. Wait until it checks for updates to extensions.
3. Load the Addons Manager.

Actual results:
The Addons Manager has an "Updates" tab, offering you an upgrade to DOM Inspector 2.0.4 (from 2.0.3).

Expected results:
The current version of DOM Inspector, rather than an obsolete one, should have been shipped with the Suite.

Additional info:
I don't dare to accept the upgrade, because I suppose the new version will be installed in my profile, while the "old" one is (I just checked) in /usr/local/seamonkey/extensions/[e-mail]/ which is rebuilt whenever I install a new nightly, so what will happen "if and when" the app ships with (let's say) DOMi 2.0.5? Will I be told to uninstall the version in my profile then? (Note: At the moment I don't have a ~/.mozilla/seamonkey/????????.default/extensions/[e-mail]/ where ???????? is a pseudorandom string generated when my profile was built)

Comment 1

[Philip Chee]

Interesting. My 2.0.1pre self build builds inspector 2.0.4. but the downloaded ZIP builds contain inspector 2.0.3. Are the nightlies built from the SEAMONKEY_2_0_RELEASE branch or from comm-191 tip?

Comment 2

[Philip Chee]

In the absence of KaiRo I talked to Gozer. Apparently both Venkman and Inspector are being built off the SEAMONKEY_2_0_RELEASE branch. He's switched them back to default. The next nightly should have DOM Inspector 2.0.4.

Comment 3

[Vlado Valastiak [:wladow]]

Venkman (and ChatZilla as well) are built off the relbranch on purpose due to the string freeze being in effect, so Venkman needs to be switched back. There's no need to build DOMi off the relbranch though (from the l10n point of view at least). KaiRo to confirm

Comment 4

[Vlado Valastiak [:wladow]]

so all 1.9.1 l10n tinderboxen are burning now due to this change. pls revert it back to relbrach ASAP. you can search #l10n logs for evidence that setting the relbranch here was intentional.

Comment 5

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6pre) Gecko/20091121 SeaMonkey/2.0.1pre - Build ID: 20091121044203

This build includes DOMi 2.0.4 and "JavaScript Debugger" 0.9.87.4. I'm not changing the status yet, since wladow's above comments seem to indicate that later builds may include earlier versions of the extensions again.

Note that earlier Sm nightlies proposed to upgrade DOMi to 2.0.4 but never told me anything about Venkman (or JavaScript Debugger).

Comment 6

[Philip Chee]

Gozer Help please!

Comment 7

[Robert Kaiser]

No need to bother gozer with that, this is a decision we need to do in the SeaMonkey team, and I'm not sure what's the right thing to do. As long as nothing is really broken, let's wait until I'm back to work.

That's my only comment until I'm back, don't count on any more comments in the next week.

Comment 8

[Philip Chee]

So I guess this means that "all 1.9.1 l10n tinderboxen are burning" translates to "nothing is really broken"

Comment 9

[Philippe M. Chiasson (:gozer)]

(In reply to comment #7)
> No need to bother gozer with that.

Given that my change is causing all l10n repacks to fail, and that this change is a matter of team decision, it feels like the safer thing to do is for me to revert that change and wait until you guys can sort all the implicaitons once KaiRo is back.

Just reverted and reconfigured buildbot master.

Comment 10

[Vlado Valastiak [:wladow]]

(In reply to comment #8)
> So I guess this means that "all 1.9.1 l10n tinderboxen are burning" translates
> to "nothing is really broken"

Well, to elabore, nothing is 'really' broken, but we don't get l10n nightly builds with ChatZilla set to being built off the default branch. The problem we're seeing here is:
1) 1.9.1 is string frozen
2) there's no 1.9.1 branch for ChatZilla
3) CZ devs are adding a new/changing existing strings
4) our build system is currently set to cause a failure for every l10n build with broken strings in CZ and Venkman (and as I understand it that's intentional due to several other bugs that need to get fixed)
so that's why KaiRo set it to the relbranch.

I don't see into KaiRo's head, maybe he has a plan already, but from how I see it the whole concept of shipping a langpacks for cz and venkman needs to be rethinked as there's a disaccord between shipping the latest addon version and strings being frozen. Not shipping the latest addon version may lead to lowering end-user experience, breaking the string freeze is adding additional pressure on releng (KaiRo) and the localizers.

I'm a localizer and from my point of view I strongly disagree to break the string freeze until there's l10n-merge turned on for cz and venkman. Once it's on and the SM team is fine with shipping these addons with mixed localized and en-US strings (in case localizer doesn't fix them) I'm fine with it. But again l10n-merge needs to be on first. 

(In reply to comment #9)
> Just reverted and reconfigured buildbot master.
Thank you.

Comment 11

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6pre) Gecko/20091122 SeaMonkey/2.0.1pre - Build ID: 20091122001126

This build is indeed back to DOMi 2.0.3. Javascript Debugger is still 0.9.87.4, which IIUC explains why I never got update prompts for it.

Comment 12

[Robert Kaiser]

The analysis of wladow in comment #10 is correct in every point.

We intentionally freeze shipped extensions for release branches as that complies with the "no new features on stable series" rule we have for the rest of the app as well. Any change to that needs a real decision by the SeaMonkey team. Still, for DOMI this is easier than for ChatZilla and venkman.

Comment 13

[Tony Mechelynck [:tonymec]]

The problem is that, unlike ChatZilla and Venkman, DOMi has seen one upgrade which is reflected in the version available at AMO but not in that shipped with Sm comm-1.9.1 nightlies even though it supports them. The result is that every day SeaMonkey tells me it found an upgrade for DOMi and asks if I want to upgrade.

BTW I'm not sure how to manage an extension which would be installed with different versions in both the profile folder tree and the one for the app-install; and I don't want to go through the rigmarole of: «uninstall DOMi (from profile), [shutdown Sm, remove the app-install folder & contents, unpack the .tar.bz2, start Sm], uninstall DOMi (from app-install), restart Sm, reinstall DOMi (into profile) from AMO, restart Sm», where the parts not in brackets (two uninstalls, one install and two restarts) are new compared with what I do now, whenever I go to the next nightly.

Comment 14

[Philip Chee]

You can let 2.0.4 install in the profile then move %profile%/extensions/[e-mail] to seamonkey/extensions/[e-mail] overriding the 2.0.3 there.

Comment 15

[Tony Mechelynck [:tonymec]]

(In reply to comment #14)
> You can let 2.0.4 install in the profile then move
> %profile%/extensions/[e-mail] to
> seamonkey/extensions/[e-mail] overriding the 2.0.3 there.

and every time I do

  cd ~/.download/mozilla
  ftp ftp.mozilla.org
   ftp> cd pub/mozilla.org/seamonkey/nightly/latest-comm-1.9.1
   ftp> ls *US.l*
   ftp> get <Tab>linux-i686.tar.bz2
   ftp> bye
  rm -Rvf /usr/local/seamonkey
  tar -jxvC /usr/local -f sea*.tar.bz2

(which is daily) I'll have to do it again, right?

Comment 16

[Philip Chee]

> (which is daily) I'll have to do it again, right?

I assume that's a shell script. So I don't see why you can't add a line or two at the end to download the latest inspector nightly and then unpack it into /usr/local/seamonkey/extensions/[e-mail]/.

Comment 17

[Robert Kaiser]

1) Please don't discuss individual strategies here on bugzilla, as dealing with someone's specific script is out of scope for Bugzilla and if this bug is declared to be about that, it's INVALID. You have been warned.

2) Comment #13 states that DOMi is different than ChatZilla and venkman in that it has released a newer version on AMO, but this is just a coincidence, it will happen with all those extensions over time, and we decided to ship them in a way that people get the updates from AMO when they are available.

3) Any profile extension always overrides the same extension in the app, i.e. when we ship with a newer version than you have in the profile, you will still use the one from the profile until you uninstall it.

4) We can't easily update all extensions to their current versions in-app in a stable release series for both the promise of no new features in a stable series and for L10n issues with ChatZilla and venkman.

There is no good and easy solution here, unfortunately.

Comment 18

[Tony Mechelynck [:tonymec]]

(In reply to comment #17)
> 1) Please don't discuss individual strategies here on bugzilla, as dealing with
> someone's specific script is out of scope for Bugzilla and if this bug is
> declared to be about that, it's INVALID. You have been warned.

OK

> 
> 2) Comment #13 states that DOMi is different than ChatZilla and venkman in that
> it has released a newer version on AMO, but this is just a coincidence, it will
> happen with all those extensions over time, and we decided to ship them in a
> way that people get the updates from AMO when they are available.
> 
> 3) Any profile extension always overrides the same extension in the app, i.e.
> when we ship with a newer version than you have in the profile, you will still
> use the one from the profile until you uninstall it.

IIUC, the only solution seems to be to install the update in the profile, which will "jam out" the version distributed with the app, even if and when the latter is someday upgraded; and the Addons Manager will display the version of the "prioritary" addon (the one in the profile if there is one), but not of the one in the install folder tree if there is one in the profile. I suppose checking whether the version in the profile is newer, equal, or older than the one in the appfolder would require starting the app with an empty profile in order to avoid the "jamming".

> 
> 4) We can't easily update all extensions to their current versions in-app in a
> stable release series for both the promise of no new features in a stable
> series and for L10n issues with ChatZilla and venkman.

...which seems to mean this bug is WONTFIX? Or is there a possibility that Sm 2.0.x will someday be shipped with a newer DOMi than 2.0.3?

> 
> There is no good and easy solution here, unfortunately.

No indeed.

Comment 19

[Serge Gautherie (:sgautherie)]

And installing extensions in profiles needs to be repeated n*m times, doesn't it?

Morphing this bug.

Comment 20

[Robert Kaiser]

The morphed bug is nothing I can work on, as it's just a question, and one that a bug cannot solve, but only a discussion can.

Comment 21

[Serge Gautherie (:sgautherie)]

(In reply to comment #20)

My main point was that bug 534422 made the initial goal 'Invalid'.
Feel free to update the summary to something more "workable"...

Comment 22

[Tony Mechelynck [:tonymec]]

(In reply to comment #21)
[...]
> Feel free to update the summary to something more "workable"...

OK, here is a first attempt, feel free to make it better. Also, this bug should probably be moved to a different Product/Component, but I'm not sure which.

Comment 23

[Philip Chee]

Closing as WORKSFORME now that we are shipping extensions in seamonkey/distribution/extensions.
1. Automatically installed into new profiles.
1.1. Normal profile addon update functions work.
2. An app update with newer extensions will copy newer extensions to the profiles.

Comment 24

[Tony Mechelynck [:tonymec]]

(In reply to comment #23)
> Closing as WORKSFORME now that we are shipping extensions in
> seamonkey/distribution/extensions.
> 1. Automatically installed into new profiles.
> 1.1. Normal profile addon update functions work.
> 2. An app update with newer extensions will copy newer extensions to the
> profiles.

Note: If a bug is fixed in one of these extensions, updating from the last nightly before the fix to the first nightly after the fix won't make the bug disappear, unless extensions.lastAppVersion is modified in about:config before Sm closedown, or in prefs.js between shutdown and startup, in order to "fake" a version update (the attempt to set it "once and for all" in user.js doesn't work). But I suppose this is regarded as "unavoidable" and should, if anything, be documented under "Known bugs and limitations".