add-ons
lolix
extensions until they are upgraded, they probably could have also
assumed that it's OK for people lo navigate the web with another
browser than FF until, well, until that other browser team comes up
with his own idea on how the IT world should be (isn't this chair
already successfully occupied by Apple ?)
FF became popular because power users tried it, found it cool and
spread the word. The same power users are now frustrated twice ;
first by this new policy, second because they are explained that they
are thinking wrong (which is perhaps true). Nevertheless, frustration
is not something you build something on. Power users will now spread
the word against FF.
Anyway, incompatible extensions are defeating the policy. So please
someone tell quickly to all those extensions that FF6 is nothing more
than FF4.2 and it's OK to plug in there. If FF6 is a lot more than FF5
which itself is a lot more that FF4 then we have a problem, that will
probably be solved by another browser.
I'm on my way to Safari.
Jorge Villalobos
Hello,
Just out of curiosity, which are the add-ons you are using that are
currently incompatible with Firefox 6?
Thanks,
Jorge Villalobos
Add-ons Developer Relations Lead
Wes Garland
>
> Anyway, incompatible extensions are defeating the policy.
Correct me if I'm wrong, but isn't current policy that Moz will insure that
all extensions hosted on addson.mozilla.org stay working on the fast release
train, provided they work on at least 4.0?
Which add-ons are broken for you? Inquiring minds want to know.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
Benjamin Smedberg
>
> all extensions hosted on addson.mozilla.org stay working on the fast release
> train, provided they work on at least 4.0?
addons as compatible with newer versions if they actually *are*
compatible. But "Mozilla" (neither the core community nor the
corporation) is not actually modifying addon code in cases where it is
truly incompatible.
--BDS
Anthony Hughes
ourselves; it is to evangelize and make it as painless as possible for
add-on developers to ensure their add-ons remain compatible.
Anthony Hughes
Quality Engineer
Mozilla Corporation
On 11-08-24 11:56 AM, Wes Garland wrote:
> On 24 August 2011 12:43, lolix<lo....@free.fr> wrote:
>
>> Anyway, incompatible extensions are defeating the policy.
>
> Correct me if I'm wrong, but isn't current policy that Moz will insure that
> all extensions hosted on addson.mozilla.org stay working on the fast release
> train, provided they work on at least 4.0?
>
Kyle Huey
> Correct me if I'm wrong, but isn't current policy that Moz will insure that
> all extensions hosted on addson.mozilla.org stay working on the fast
> release
> train, provided they work on at least 4.0?
>
It's something more like "addons on addons.mozilla.org will have their
maxVersion automatically bumped to the next release if they are compatible
with the current release and the automated analysis does not see any
problems (e.g. using removed interfaces)"
- Kyle
David E. Ross
No, this is not happening. The maxVersion in an extension's install.rdf
file is current not touched. Instead, AMO sends some kind of override
signal to the Add-ons Manager in the user's application, which requires
that an Internet connection be active.
See bug #677458 at <https://bugzilla.mozilla.org/show_bug.cgi?id=677458>.
--
David E. Ross
<http://www.rossde.com/>
On occasion, I might filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam from that source.
Wes Garland
> It's something more like "addons on addons.mozilla.org will have their
> maxVersion automatically bumped to the next release if they are compatible
> with the current release and the automated analysis does not see any
> problems (e.g. using removed interfaces)"
>
>
Ah -- thanks for the clarification, all.
When I heard that original announcement (on IRC? slashdot?) I was quite
flabbergasted, and impressed at the same time.
khuey's clarification makes a lot of sense, and is, IMO, a pretty reasonable
approach.
Jorge Villalobos
> On 8/24/11 12:08 PM, Kyle Huey wrote:
>> On Wed, Aug 24, 2011 at 2:56 PM, Wes Garland<w...@page.ca> wrote:
>>
>>> Correct me if I'm wrong, but isn't current policy that Moz will insure that
>>> all extensions hosted on addson.mozilla.org stay working on the fast
>>> release
>>> train, provided they work on at least 4.0?
>>>
>>
>> It's something more like "addons on addons.mozilla.org will have their
>> maxVersion automatically bumped to the next release if they are compatible
>> with the current release and the automated analysis does not see any
>> problems (e.g. using removed interfaces)"
>>
>> - Kyle
>
> No, this is not happening. The maxVersion in an extension's install.rdf
> file is current not touched. Instead, AMO sends some kind of override
> signal to the Add-ons Manager in the user's application, which requires
> that an Internet connection be active.
>
> See bug #677458 at<https://bugzilla.mozilla.org/show_bug.cgi?id=677458>.
>
Yes, what we update is the metadata on AMO, which is something
developers can also change on their own. If you install your add-on from
AMO, the updated metadata overrides whatever is in install.rdf and the
add-on should work correctly.
If the add-on was downloaded from AMO, Firefox will check on AMO for
updates on a daily basis, updating compatibility metadata when
necessary. In the case of a Firefox update, this updated data should be
downloaded when Firefox checks for add-on compatibility. If there's no
Internet connection while this occurs, the incompatible add-ons will be
disabled, at least until Firefox checks for updates again and find
updated compatibility information, or a new compatible version of the
add-on.
- Jorge
David E. Ross
But all this requires an active Internet connection. If I download an
extension's XPI file and then disconnect from the Internet before
installing it, Add-ons Manager refuses to do the installation unless
maxVersion in the install.rdf file indicates compatibility with the
current application version. (I have become quite adept at extracting,
updating, and re-inserting install.rdf in XPI files.)
No, I am not the only one who installs extensions while off-line. A
lengthy discussion in the mozilla.support.thunderbird newsgroup clearly
indicated that others also attempt to install extensions while off-line.
Wes Garland
at large.
I'm sure I'm not the only one who mis-understood the add-on compatibility
situation, and it is especially important now that we are on the fast
release train.
Wes
On 24 August 2011 16:13, Jorge Villalobos <jo...@mozilla.com> wrote:
> On 8/24/11 1:56 PM, David E. Ross wrote:
>
>> On 8/24/11 12:08 PM, Kyle Huey wrote:
>>
>>> On Wed, Aug 24, 2011 at 2:56 PM, Wes Garland<w...@page.ca> wrote:
>>>
>>> Correct me if I'm wrong, but isn't current policy that Moz will insure
>>>> that
>>>> all extensions hosted on addson.mozilla.org stay working on the fast
>>>> release
>>>> train, provided they work on at least 4.0?
>>>>
>>>>
>>> It's something more like "addons on addons.mozilla.org will have their
>>> maxVersion automatically bumped to the next release if they are
>>> compatible
>>> with the current release and the automated analysis does not see any
>>> problems (e.g. using removed interfaces)"
>>>
>>> - Kyle
>>>
>>
>> No, this is not happening. The maxVersion in an extension's install.rdf
>> file is current not touched. Instead, AMO sends some kind of override
>> signal to the Add-ons Manager in the user's application, which requires
>> that an Internet connection be active.
>>
>> See bug #677458 at<https://bugzilla.mozilla.**org/show_bug.cgi?id=677458<https://bugzilla.mozilla.org/show_bug.cgi?id=677458>
>> >.
>>
>>
> Yes, what we update is the metadata on AMO, which is something developers
> can also change on their own. If you install your add-on from AMO, the
> updated metadata overrides whatever is in install.rdf and the add-on should
> work correctly.
>
> If the add-on was downloaded from AMO, Firefox will check on AMO for
> updates on a daily basis, updating compatibility metadata when necessary. In
> the case of a Firefox update, this updated data should be downloaded when
> Firefox checks for add-on compatibility. If there's no Internet connection
> while this occurs, the incompatible add-ons will be disabled, at least until
> Firefox checks for updates again and find updated compatibility information,
> or a new compatible version of the add-on.
>
> - Jorge
>
> ______________________________**_________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-planning<https://lists.mozilla.org/listinfo/dev-planning>
Jorge Villalobos
I haven't read that discussion, but I would assume that this is related
to the fact there used to be no clear installation flow for TB and users
ended up downloading them and the installing them when they remembered
to do so. I wonder if that will improve now that Thunderbird has an
Add-ons Manager with integrated search and installation. That won't
eliminate all needs for offline installation, but it could remove most.
We don't touch add-on packages for the most part because we don't want
to unintentionally break any add-ons. Any solution that requires add-on
modification would need to exclude signed extensions, which are rare but
still exist. It would also negate many packaging optimizations
developers might have introduced after careful performance testing.
While there are bugs in the current approach, I think it's the best of
the possible solutions. Developer who have been bitten by these bugs
usually upload new versions, even if the only change is the
compatibility information. Editors will always reply indicating that
they can change the metadata on AMO, but they are also required to
approve those updates.
- Jorge
Ron Hunter
> On 8/24/11 12:08 PM, Kyle Huey wrote:
>> On Wed, Aug 24, 2011 at 2:56 PM, Wes Garland<w...@page.ca> wrote:
>>
>>> Correct me if I'm wrong, but isn't current policy that Moz will insure that
>>> all extensions hosted on addson.mozilla.org stay working on the fast
>>> release
>>> train, provided they work on at least 4.0?
>>>
>>
>> It's something more like "addons on addons.mozilla.org will have their
>> maxVersion automatically bumped to the next release if they are compatible
>> with the current release and the automated analysis does not see any
>> problems (e.g. using removed interfaces)"
>>
>> - Kyle
>
> No, this is not happening. The maxVersion in an extension's install.rdf
> file is current not touched. Instead, AMO sends some kind of override
> signal to the Add-ons Manager in the user's application, which requires
> that an Internet connection be active.
>
> See bug #677458 at<https://bugzilla.mozilla.org/show_bug.cgi?id=677458>.
>
compatibility? I am getting the idea from user comments that it isn't.
Many are saying 'All my add-ons got disabled.'
Ron Hunter
uncommon that the developers never considered that case, hence, didn't
provide for it.
Chris Ilias
> On 24 August 2011 15:08, Kyle Huey<m...@kylehuey.com> wrote:
>
>> It's something more like "addons on addons.mozilla.org will have their
>> maxVersion automatically bumped to the next release if they are compatible
>> with the current release and the automated analysis does not see any
>> problems (e.g. using removed interfaces)"
>>
>>
> Ah -- thanks for the clarification, all.
>
> When I heard that original announcement (on IRC? slashdot?) I was quite
> flabbergasted, and impressed at the same time.
They probably pointed to
http://blog.mozilla.com/addons/2011/05/21/firefox-5-compatibility-bump/
lolix
DNS cache (flusher) https://addons.mozilla.org/en-US/firefox/addon/dns-cache/
among others.
I installed it to quite a few roaming users who are now all calling
me.
This DNS cache maintained by FF is an annoyance and out of the scope
of a browser but that's another debate.
There are plenty other DNS cache flusher extension (the proof that
this caching a real annoyance). I won't spend time to carefully select
one just to discover in 6 weeks from now that it is no more
compatible. So I'll pick one at random until I have carefully selected
another browser (that don't do DNS caching BTW).
I'm confident that incompatibles extension will defeat the Rapide
Release policy
Boris Zbarsky
> DNS cache (flusher) https://addons.mozilla.org/en-US/firefox/addon/dns-cache/
> among others.
It's not clear to me why this extension is not marked compatible. In
particular, why it didn't get auto-bumped.
Jorge, any idea why that happened?
> another browser (that don't do DNS caching BTW).
Chrome has a DNS cache (and in fact one that's longer-lived than ours).
Opera has a DNS cache.
Safari and IE seem to just use the OS DNS cache, which is easier for
them because they can get it tweaked to their needs as necessary.
-Boris
Wes Garland
does firefox not obey the timeout fields in the SOA record?
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
lolix
> I'm curious -- what is wrong with your DNS that requires manual flushing? Or
> does firefox not obey the timeout fields in the SOA record?
>
computers.
The thing is that this name exists also on the internet side, except
that it is then a simple alias for
ssl.mycompany.com which is a secure portal for roaming staff.
I'm not the one who setup this. I don't know if it's best practice or
not. My network colleagues did.
Clients have therefore to deal with two @ip for the same name,
depending on their connection.
When roaming staff comes back inside, FF points to ssl.mycompany.com
(which is a server available both inside an outside). Then a manual
flush is required (or turning off FF dns caching).
Jorge Villalobos
There are a number of reasons it for it not being bumped. Maybe it
wasn't compatible with Firefox 4 when we ran the bump from 4 to 5, or
maybe there is something in it that is incompatible with 5. There were
also a number of bugs in the bulk validation that have been fixed in the
meantime. I haven't really looked at the validation results or the log
to be sure.
Since the add-on is already 2 releases behind, I suspect it is no longer
being maintained by the developer.
- Jorge
Boris Zbarsky
> There are a number of reasons it for it not being bumped. Maybe it
> wasn't compatible with Firefox 4 when we ran the bump from 4 to 5, or
> maybe there is something in it that is incompatible with 5. There were
> also a number of bugs in the bulk validation that have been fixed in the
> meantime. I haven't really looked at the validation results or the log
> to be sure.
I know what the general reasons it might not have been bumped are... I
was wondering what the specific reasons were for this add-on.
-Boris
lolix
>
> Since the add-on is already 2 releases behind,
Do you mean more than 12 weeks old ? Maybe this bastard had some
vacation during summer and some job he's paid for to do as well.
Just kidding.
BTW, Rapid Release was something already in place at the early age of
the Internet when we used NCSA Mosaic.
We used to get a new version every week or something. No add-ons at
that time, though.
Jorge Villalobos
According to the log, it should have been upgraded to Firefox 5, but it
wasn't. This was probably caused by a bug in the bulk validation code.
See bug 658944 and bug 682999.
- Jorge
Boris Zbarsky
> According to the log, it should have been upgraded to Firefox 5, but it
> wasn't. This was probably caused by a bug in the bulk validation code.
> See bug 658944 and bug 682999.
OK. Is it possible to rerun the bump script on this extension now and
see what it says?
-Boris
Jorge Villalobos
Running the 4.* -> 5.* bump would yield the same result (PASS), and it
can't be run for individual add-ons. All other compat bumps (5.* -> 6.*,
etc.) would need to be run in sequence after bumping its compatibility,
in order to potentially increase its compatibility up to Firefox 8.
While this could be done manually for this particular extension, it
can't be done for all, since it would be too spammy to run all these
bumps again and resend many emails that developers have already received
before.
- Jorge
Ron Hunter
Henri Sivonen
> While this could be done manually for this particular extension, it can't be
> done for all, since it would be too spammy to run all these bumps again and
> resend many emails that developers have already received before.
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Jorge Villalobos
> On Wed, Sep 7, 2011 at 8:11 PM, Jorge Villalobos<jo...@mozilla.com> wrote:
>> While this could be done manually for this particular extension, it can't be
>> done for all, since it would be too spammy to run all these bumps again and
>> resend many emails that developers have already received before.
>
> Why can't the emails be turned off if they are too spammy?
>
Well, we can't give developers an automatic upgrade without telling
them. But we do have the possibility not sending the messages for those
who didn't pass the compatibility checks. It would still suck for
developers who were incorrectly bumped and had to downgrade their add-on
back, because they would need to do it again.
Finally, at the moment we don't have a fine-grained system that allows
developers to opt-out to the compatibility bumps or those specific
emails. The only option we give them is to disable their add-on, or stay
behind the Aurora compatibility cycle so their add-on doesn't qualify
for future bumps.
- Jorge
Jorge Villalobos
>> While this could be done manually for this particular extension, it can't be
>> done for all, since it would be too spammy to run all these bumps again and
>> resend many emails that developers have already received before.
>
> Why can't the emails be turned off if they are too spammy?
>
Well, we can't give developers an automatic upgrade without telling