Extension development for beta
axel.grude at gmail.com
Mon Oct 29 12:37:51 UTC 2018
no there was an actual "beta channel" within the ADd-ons: if you uploaded a Add-on
with the string "b / a / beta / alpha / pre" contained in the version number it would
be marked as such and not shown on the main page but listed in versions. If a user
installed that they would go on the "beta-trail" and be updated with other betas. (As
far as I remember). I think the disadvantage was that new "release" versions would not
auto-update users on the beta-trail, so if you didn't release newer betas, then beta
users would eventually be "left behind".
Of course it is possible that I imagined the whole thing, but I did have beta releases
for QuickFolders for a while. It could also have been a checkbox on the AMO submission
form. Maybe Jorge remembers.
*Axel Grude <mailto:axel.grude at gmail.com>*
Music Production and Composition
Thunderbird Add-ons Developer (QuickFolders
QuickPasswords <https://addons.mozilla.org/firefox/addon/quickpasswords/>, Zombie Keys
Visit my YouTube Channel <https://www.youtube.com/c/thunderbirddaily> for email
productivity tips Get Thunderbird!
> *Subject:*Re: Extension development for beta
> *From:*Magnus Melin <mkmelin+mozilla at iki.fi>
> *To:*<tb-planning at mozilla.org>
> *Sent: *Monday, 10/29/2018 11:10 GMT ST +0000 [Week 44]
> Seems I slightly misread this, but perhaps my misconception could be an idea:
> Play store has a Firefox for Android Beta. Perhaps extensions should do the same,
> i.e. the Foobar extension should have a separate FoobarBeta extension that is
> targeting the beta channel users?
> On 29-10-2018 12:04, Axel Grude wrote:
>> Dear Geoff,
>> please don't confuse ESR60 with Thunderbird beta. (tb63) - the ESR (thunderbird
>> 60.*) supports using install.rdf - so you can keep using that unless you want to
>> support beta versions.
>> For testing beta versions I would suggest creating a separate batch script for
>> buildng. I haven't managed to get mine fully compatible yet but it should be
>> definitely possible to start from the same sources without being forced to "fork"
>> code at this stage - let the batch script do the rest. You will need to build 2
>> different versions but you can use minver & maxver to control the behavior on ATN.
>> Nothing stops you from releasing both versions alternately - they should be picked
>> up by the update mechanism based on minver / maxver.
>> As regards having a separate beta trail, I think this would be the best option (we
>> had this on AMO but I think it was removed again). Is this something that ATN could
>> *Axel Grude <mailto:axel.grude at gmail.com>*
>> Music Production and Composition
>> Thunderbird Add-ons Developer (QuickFolders
>> quickFilters <https://addons.mozilla.org/thunderbird/addon/quickfilters/>,
>> QuickPasswords <https://addons.mozilla.org/firefox/addon/quickpasswords/>, Zombie
>> Keys <https://addons.mozilla.org/thunderbird/addon/zombie-keys/>, SmartTemplate4
>> Visit my YouTube Channel <https://www.youtube.com/c/thunderbirddaily> for email
>> productivity tips Get Thunderbird!
>>> *Subject:*Extension development for beta
>>> *From:*Geoff Lankow geoff at thunderbird.net
>>> *To:*<tb-planning at mozilla.org>
>>> *Sent: *Monday, 10/29/2018 08:37 GMT ST +0000 [Week 44]
>>> We have a problem. Actually, a series of problems.
>>> Firstly. For an extension to run on ESR60, it must be:
>>> 1. an overlay extension with an install.rdf manifest, or
>>> 2. a bootstrapped extension with an install.rdf manifest, or
>>> 3. a WebExtension with a manifest.json
>>> C is very rare, because ESR60 supports so few of the WebExtension APIs. B isn't an
>>> issue yet but will become one soon, so I'm ignoring it for this conversation.
>>> For A to run on beta, it must have a manifest.json and /NOT/ have an install.rdf
>>> manifest. (At this point it's technically a WebExtension and we're just lying to
>>> the extensions back-end about what it's actually doing.)
>>> This leads to the second problem: it's impossible to have an extension that both
>>> has an install.rdf and doesn't have an install.rdf. Therefore an extension
>>> developer cannot make an extension that can run on both ESR60 and beta.
>>> (Side note: I've been trying to make a backport for ESR that can run an updated
>>> legacy extension, but I'm uncomfortable with the size of the changes.)
>>> The extension developer /could/ make a separate version of their extension which
>>> is only for beta. Given the other big changes in the platform, that's probably the
>>> best option anyway, but that takes us to problem three: they can't host the beta
>>> version of their extension on ATN, because ATN no longer has support for
>>> development channel extensions. I /think/ there's an ugly workaround involving
>>> uploading versions out-of-order such that the ESR version is the one displayed,
>>> but I really don't think developers should have to deal with that, or would
>>> bother. They could also self-host the extension but I think most wouldn't want to
>>> do that.
>>> We're left with a bunch of not-very-nice options, as well as all the other issues
>>> facing extension developers, which I think is just going to put a lot of
>>> developers off altogether, and we'll lose a large fraction of our extensions.
>>> tb-planning mailing list
>>> tb-planning at mozilla.org
>> tb-planning mailing list
>> tb-planning at mozilla.org
> tb-planning mailing list
> tb-planning at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 846 bytes
Desc: not available
More information about the tb-planning